ysyneu · Oct 26, 2026 · Oct 26, 2026 · Oct 26, 2026 · Oct 26, 2026
diff --git a/en/ai-sre/sessions.mdx b/en/ai-sre/sessions.mdx
@@ -67,7 +67,7 @@ A new session gets an automatic title after its first turn; you can rename it at
 
 | Indicator | Meaning |
 |---|---|
-| Spinning circle | The agent is running |
+| Spinning circle | The agent is running: either the current turn is executing, or a dispatched subagent is still running |
 | 🔭 + number | Number of background tasks running — see [Task Panel and Background Tasks](#task-panel-and-background-tasks) |
 | Blue dot | New content you have not seen; cleared when you open the session |
 | Relative time | Last activity (for example, `5m`, `3h`) |
@@ -112,7 +112,9 @@ While a turn runs, the Send button becomes a **Stop** button. Stopping interrupt
 
 ### Queueing messages while running
 
-You can keep sending messages while a turn runs; they queue and run in order after the current turn. Queued messages appear above the input, where you can edit, remove or **Clear all** of them. Once the agent has started on a message it can no longer be withdrawn; use Stop to interrupt.
+**While the current turn is executing**, you can keep sending messages; they queue and run in order after the current turn. Queued messages appear above the input, where you can edit, remove or **Clear all** of them. Once the agent has started on a message it can no longer be withdrawn; use Stop to interrupt.
+
+**Once the agent has handed the work to a subagent and its own turn has ended**, the session still counts as running (the list still shows the spinning circle, and the button beside the input is still Stop), but the main agent is idle: a message you send then does **not** queue, it starts a new turn immediately. The same holds after a page refresh, so the session is never mistaken for "executing" and your messages are not held back.
 
 ### Environment initialization
 
@@ -150,13 +152,24 @@ If you send a new message instead of answering, the question is treated as skipp
 
 Some console pages **declare that AI can operate them**: each turn sends the agent the actions available on the page you are viewing, so on these pages the agent can read and fill in the form directly instead of only giving written advice.
 
-Currently this covers the **Alert grouping** and **Flapping detection** pages under a channel's Noise reduction; see [Noise reduction](/en/on-call/channel/noise-reduction). Other pages have no page actions, so the agent cannot operate them. Page actions exist only in console sessions, not in IM, API, or automation sessions.
+The console pages that declare page actions:
+
+| Page | What the agent can do |
+|---|---|
+| The **Alert grouping** and **Flapping detection** pages under a channel's Noise reduction (see [Noise reduction](/en/on-call/channel/noise-reduction)) | Read the form and fill in fields; actions that take effect immediately, such as **Save**, are confirmed one at a time |
+| The **RUM Explorer** (see [Query and analyze with AI SRE](/en/rum/explorer/data-query#query-and-analyze-with-ai-sre)) | Look up field values, rewrite the query and event type, move the time range, set up the analytics chart; writes land straight on the page and are reverted with **Undo change** |
+
+Other pages have no page actions, so the agent can only give written advice. Page actions exist only in console sessions, not in IM, API, or automation sessions.
+
+Actions on the **Alert grouping** and **Flapping detection** pages work like this:
 
 - **Reading** the form (fields, current values, options, whether writable) needs no authorization.
 - **Filling** a field only writes the value into the form; it does not submit. Review it and click **Save** yourself.
 - **Saving**, and other actions that take effect immediately, each pop up their own confirmation card in the conversation (above the input), listing "old value → new value" with **Cancel** and the action's own verb (such as **Save**).
 
-Before touching the page, the agent asks with a question card how to apply the change: fill the form for you to review and save, or save directly. While it works, the page gets a brand-colored highlight and an **AI is working on this page** bar at the top, which changes to **Done** when finished; you can click **Stop** to interrupt. Sending a new message or leaving the session voids any unanswered confirmation card. In a shared session opened read-only, page actions do not run.
+Before touching either of those pages, the agent asks with a question card how to apply the change: fill the form for you to review and save, or save directly. While it works, the page gets a brand-colored highlight and an **AI is working on this page** bar at the top, which changes to **Done** when finished; you can click **Stop** to interrupt. Sending a new message or leaving the session voids any unanswered confirmation card. In a shared session opened read-only, page actions do not run.
+
+Writes on the **RUM Explorer** raise no confirmation card: the agent rewrites the query box, the event type, the time range and the analytics chart, and runs them right away. The AI SRE bar under the query box reports progress and the result (**Filling in the query**, **Querying**, then the number of events found, **Query complete**, or **Query complete, no data**). To get back the page you had before the write, click **Undo change** on that bar. Looking up which values a field holds does not change the page.
 
 ### When authorization is required
 
@@ -319,6 +332,17 @@ The **reply language** is set when the session is created and used for the whole
 
 This section is for developers integrating AI SRE sessions through the [Open API](/en/api-reference/ai-sre/sessions/session-read-info).
 
+### Session run state
+
+Both `POST /safari/session/get` and `POST /safari/session/list` return two run-state fields, and they mean different things:
+
+| Field | Meaning |
+|---|---|
+| `is_running` | The session holds a running state: the current turn is executing, **or** a dispatched subagent's round has not ended. Running background commands and monitors do not count |
+| `turn_in_flight` | Whether the current turn is actually executing |
+
+After the agent hands work to a subagent, its own turn ends first: during that window `is_running` stays `true` while `turn_in_flight` is `false`. Read `turn_in_flight` to know whether a message sent now will queue, and `is_running` to know whether the session is still working. Both are computed in the response, so they describe the moment you query.
+
 ### Withdrawing a queued message
 
 The `pending_messages` field in the `POST /safari/session/get` response lists queued messages the agent has not read yet, in execution order. Before the agent reads one, its author can withdraw it with `POST /safari/session/message/cancel`, passing `session_id` and `invocation_id` (the invocation ID returned when the message was sent). The `result` field means:

diff --git a/en/changelog/changelog.mdx b/en/changelog/changelog.mdx
@@ -4,6 +4,22 @@ description: "This page documents important updates and feature releases for Fla
 keywords: ["Changelog", "Product Release", "Feature Updates", "Flashduty", "Version History"]
 ---
 
+<Update label="2026-10-25" description="🧭 Query and analyze in the RUM Explorer with AI SRE, a custom dashboard belongs to one application, errors split into Issues by where they were raised">
+
+### RUM Explorer: query and analyze with AI SRE
+
+The sparkle at the left of the query box opens AI SRE now — on an account with AI SRE enabled, for a member who may chat in it; ⌘ + Enter in normal query mode does the same, Ctrl + Enter on Windows and Linux. Say in one sentence what you are looking for and AI SRE writes it into the page: the box's conditions, the event type, the time range, and the chart in analytics, then runs the query itself. The status bar under the query box reports the turn — filling in the query, querying (counting seconds past 3), N found, query complete, no data, query failed, stopped; **Undo change** puts the page back the way it was before the write, and works only while the box still holds what AI SRE wrote. **Stop** ends a running turn; clicking the status bar or pressing Esc only folds the conversation without ending it, leaving the results in view. An account without AI SRE, or one out of AI SRE credits, keeps the basic natural-language query at the same entry: a sentence becomes DQL, previewed before you apply it. See [Data query syntax guide](/en/rum/explorer/data-query).
+
+### RUM dashboards: a dashboard belongs to one application
+
+A custom dashboard now belongs to the application it was created in, and every panel's query reads that application only, so the panel editor drops its application picker: the old **Page application** option (`$app`, resolved to the page's current application) survives only in definitions saved before this change. The Insights tab bar lists the current application's dashboards (by title, up to 100) and **Manage dashboards** lists every application's; opening another application's dashboard from the manage page or a link first switches the page to the application it belongs to, then opens it. Switching the application by hand on a dashboard tab leaves that dashboard and returns to the **Overview** tab, which belongs to the new application. A copy of another application's dashboard stays in that application. Dashboards saved before this change take the application of their first query that reads a concrete one; an old dashboard that reads no concrete application no longer appears in the application's tabs and can no longer be edited, so create it again under its application. See [RUM custom dashboards](/en/rum/analytics/custom-dashboards).
+
+### RUM errors split by where they were raised
+
+The same error message raised from two different places in the code now makes two Issues instead of one. The location is taken from what survives a rebuild: for a Web JS error, the script and function of its top meaningful stack frame; for Android, the throw site of the exception chain's root cause plus the first app-code frame below it; for an iOS crash, the crash site plus the first app-code frame below it — line and column numbers, build hashes and minified or obfuscated names take no part, so a new release does not split one bug into new Issues. A minified frame that cannot be told apart is not used as a location, and such errors keep grouping by type and message. An iOS frame the SDK could not resolve can only be told apart by its offset inside the image, and that offset is stable within one build only, so such a crash can become a new Issue after every release — uploading dSYMs changes how the stack reads in the console, not how it is grouped. Existing browser and Android Issues keep receiving their message from every location, with their status, assignee and history; iOS crashes do not carry over to the old signal-only Issue and start anew by crash location. A custom fingerprint still takes precedence. See [Error grouping](/en/rum/error-tracking/error-aggregation).
+
+</Update>
+
 <Update label="2026-10-20" description="📋 Table and card views for routing rules, and connector credentials no longer follow a changed destination">
 
 ### Routing rules in a table or card view
@@ -20,7 +36,7 @@ The people who can edit an MCP server or an A2A agent are not necessarily the pe
 
 ### RUM custom dashboards: build your own under Insights
 
-The Insights tab bar no longer holds only the built-in dashboards: the **+** menu at its right end offers **New dashboard** (requires the **Dashboards Manage** permission) and **Manage dashboards**, and a custom dashboard opens as an extra tab (up to 100 tabs are listed); **Save to dashboard** on an analytics chart also turns the current question into one full-width panel. A panel asks the same aggregation question as the explorer — application (or the built-in `$app` variable, which follows the page's current application), event type, aggregation and field, group by and top N, plus a DQL filter — and draws as a time series, table, stat or text panel. Dashboard variables come in field-value and custom kinds, referenced in a panel's DQL as `${name}`, and a new dashboard starts with `env` / `service` / `version` field variables. Every save leaves a revision (the last 20 are kept), and a deleted dashboard goes to the trash for 30 days and can be restored from the manage page. See [RUM custom dashboards](/en/rum/analytics/custom-dashboards).
+The Insights tab bar no longer holds only the built-in dashboards: the **+** menu at its right end offers **New dashboard** (requires the **Dashboards Manage** permission) and **Manage dashboards**, and a custom dashboard opens as an extra tab (up to 100 tabs are listed); **Save to dashboard** on an analytics chart also turns the current question into one full-width panel. A panel asks the same aggregation question as the explorer — event type, aggregation and field, group by and top N, plus a DQL filter (since 2026-10-25 a dashboard belongs to one application and its panels always read that application) — and draws as a time series, table, stat or text panel. Dashboard variables come in field-value and custom kinds, referenced in a panel's DQL as `${name}`, and a new dashboard starts with `env` / `service` / `version` field variables. Every save leaves a revision (the last 20 are kept), and a deleted dashboard goes to the trash for 30 days and can be restored from the manage page. See [RUM custom dashboards](/en/rum/analytics/custom-dashboards).
 
 ### A redesigned template detail page, with send test
 

diff --git a/en/developer/cli.mdx b/en/developer/cli.mdx
@@ -763,12 +763,16 @@ Common `create` flags:
 | `--disabled` | Create the rule disabled (enabled by default) |
 | `--schedule-enabled` | Whether the schedule trigger is enabled (default `true`) |
 | `--http-post-trigger` | Create and enable an HTTP POST trigger; when passed alone without any schedule flags, the CLI writes a placeholder cron and disables the schedule trigger |
+| `--war-room-trigger` | Create and enable the war room creation trigger; requires `--war-room-channel-ids` and `--war-room-severities` together, and errors if either is missing. When passed alone without any schedule flags, the CLI likewise writes a placeholder cron and disables the schedule trigger (same as `--http-post-trigger`); passed together with `--schedule` and the other schedule flags, the schedule trigger stays enabled |
+| `--war-room-channel-ids` / `--war-room-severities` | Match conditions for the war room trigger: the channel (collaboration space) IDs to watch (comma-separated, at least one) and the severities (`Critical`, `Warning`, `Info`; comma-separated, at least one). Both must be given together when the trigger is created |
 | `--prompt` / `--prompt-file` | Task prompt, exactly one required; `--prompt-file` reads from a file (`-` for stdin) |
 | `--environment-kind` / `--environment-id` | Runtime environment: `cloud` or `byoc` (`byoc` requires `--environment-id`); empty means automatic |
 
 When you create a rule from an IM conversation, omitting `--run-in` lets the server bind the rule to that conversation and inherit its scope; you neither need to nor should pass a chat, platform, integration, or session ID — the server resolves and authorizes the current conversation. Once bound to a conversation, every ordinary run starts a fresh execution session and, where the IM integration creates threads, a fresh IM thread, and it stays on the conversation and immutable scope captured at creation rather than reusing an old session or thread; a retry of the same run reuses that run's execution identity. If the bound conversation's scope no longer matches the rule when it runs, the run is skipped — the rule is never moved or run in another conversation. War-room Automations keep their existing behavior. Because each run starts from a fresh context, write the prompt so it carries the chat context it needs (the service, the team, the delivery target) and do not refer to "above" or to an earlier session. Like the scope, the execution destination is immutable after creation.
 
-`update` accepts `--name`, `--prompt`/`--prompt-file`, `--schedule`/`--at`/`--weekday`/`--cron-expr`/`--timezone`, `--enable`/`--disable`, `--enable-schedule`/`--disable-schedule`, `--enable-http-post-trigger`/`--disable-http-post-trigger`, `--rotate-http-post-token`, and `--environment-kind`/`--environment-id`. The personal/team scope and the execution destination (`--run-in`) are both immutable after creation, so `update` exposes neither. `update`'s `--cron-expr` carries the same constraint as `create`: the minute must be a fixed `0`–`59` integer, so the fastest schedule is hourly, and minute wildcards, ranges, lists, and steps are unsupported.
+The war room creation trigger starts a run whenever a war room (IM group chat) is created in one of the matching channels. That run's session lives in the war room's group chat, not in the console — `--run-in` does not apply to it, and it uses the execution environment already chosen in that group chat, so the rule's own environment does not affect it. Field semantics and run behaviour: [Automations · War room created](/en/ai-sre/automations#war-room-created).
+
+`update` accepts `--name`, `--prompt`/`--prompt-file`, `--schedule`/`--at`/`--weekday`/`--cron-expr`/`--timezone`, `--enable`/`--disable`, `--enable-schedule`/`--disable-schedule`, `--enable-http-post-trigger`/`--disable-http-post-trigger`, `--rotate-http-post-token`, `--enable-war-room-trigger`/`--disable-war-room-trigger`, `--war-room-channel-ids`/`--war-room-severities`, and `--environment-kind`/`--environment-id`. `--enable-war-room-trigger` and `--disable-war-room-trigger` are mutually exclusive and error if both are passed; `--war-room-channel-ids`/`--war-room-severities` replace the trigger's filters wholesale when passed, and the server requires both lists when `update` first creates the war room trigger. The personal/team scope and the execution destination (`--run-in`) are both immutable after creation, so `update` exposes neither. `update`'s `--cron-expr` carries the same constraint as `create`: the minute must be a fixed `0`–`59` integer, so the fastest schedule is hourly, and minute wildcards, ranges, lists, and steps are unsupported.
 
 `runs` supports `--status` (`queued`/`running`/`retrying`/`succeeded`/`partial`/`failed`/`skipped`/`abandoned`), `--trigger-kind` (server-side values `schedule`/`debug`/`manual`/`http_post`/`oncall_incident`/`war_room_created`, where `war_room_created` is a run triggered by a war room being created), `--since`/`--until`, `--page`, and `--limit`. `fire` authenticates with the trigger's token (`--token`, or the `FLASHDUTY_AUTOMATION_TRIGGER_TOKEN` environment variable); `--text` passes context for the run, and `--data` passes a full JSON request body (inline JSON or `-` to read stdin).