diff --git a/en/ai-sre.mdx b/en/ai-sre.mdx
index c735110f2..69b411752 100644
--- a/en/ai-sre.mdx
+++ b/en/ai-sre.mdx
@@ -42,7 +42,7 @@ It's a **hands-on troubleshooter** built into Flashduty incident response. When
@-mention AI SRE in Slack / Feishu / DingTalk / WeCom to start or continue an investigation, visible to the whole team
- When you open an IM war room for an incident, AI SRE runs an initial diagnosis and posts the conclusion back automatically
+ When you open an IM war room for an incident and an enabled **War room created** automation rule matches it, AI SRE runs an initial diagnosis and posts the conclusion back automatically
Use /insight to review the last 30 days of sessions, quantify operational friction, and get reproducible improvement suggestions
diff --git a/en/ai-sre/automations.mdx b/en/ai-sre/automations.mdx
index 022c01c55..2f08d9d2d 100644
--- a/en/ai-sre/automations.mdx
+++ b/en/ai-sre/automations.mdx
@@ -1,7 +1,7 @@
---
title: Automations
-description: Have AI SRE run a hidden session automatically on a cron schedule, through an HTTP API, or from an On-call incident event, driven by a task prompt, to produce inspection, insight, or post-mortem results. This page covers creating automation rules, configuration fields, triggers, run history, and permissions.
-keywords: ["AI SRE", "Automation", "inspection", "scheduled task", "cron", "HTTP trigger", "On-call incident trigger", "manual run", "run history", "hidden session"]
+description: Have AI SRE run a task automatically on a cron schedule, through an HTTP API, from an On-call incident event, or when a war room is created, driven by a task prompt, to produce inspection, insight, or post-mortem results. This page covers creating automation rules, configuration fields, triggers, run history, and permissions.
+keywords: ["AI SRE", "Automation", "inspection", "scheduled task", "cron", "HTTP trigger", "On-call incident trigger", "war room created trigger", "manual run", "run history", "hidden session"]
sidebarTitle: Automations
---
@@ -16,13 +16,14 @@ Each automation is a **rule**. A rule carries at least one trigger:
- **Schedule (cron)**: set the cadence with a 4-field or 5-field cron expression (for example, every Monday morning or every day at 09:15); it runs automatically when the time comes.
- **Call via API**: generate a trigger URL with a Bearer token. An external system triggers the rule on demand with a `POST` and passes the context for the run in the request body.
- **On-call incident trigger**: select the On-call channels and severities to watch, then start a diagnostic run when a matching incident appears.
+- **War room created**: select the channels and severities to watch, then start a diagnostic run when a matching incident gets a war room. This run's session lives in the war room's IM group chat, not in the console.
When to use it: hand recurring routine inspections (such as a daily health check) and periodic insight / post-mortem reports to AI SRE to run automatically. Or wire AI SRE into your existing pipeline, change system, or On-call incident flow so an event kicks off a diagnosis.
Entry point: **AI SRE → Automations** in the left navigation, route `/ai-sre/automations`.
-Every run produced by an automation is, at its core, still an AI SRE session — it is marked as hidden and not mixed into your everyday session list. You can always click into it from the run history to see the full conversation, tool calls, and artifacts of that run.
+Every run produced by an automation is, at its core, still an AI SRE session — it is marked as hidden and not mixed into your everyday session list. You can always click into it from the run history to see the full conversation, tool calls, and artifacts of that run (except for a **War room created** run, which runs in the IM group — see "War room created" below).
## Creating an automation
@@ -58,7 +59,7 @@ For **Environment**, "Auto" has the system pick the best available environment a
## Triggers
-A rule must have **at least one trigger** configured. The current console form exposes **Schedule**, **Call via API**, and **On-call incident** in the "Triggers" section, and all three can be enabled at the same time.
+A rule must have **at least one trigger** configured. The current console form exposes **Schedule**, **Call via API**, **On-call incident**, and **War room created** in the "Triggers" section, and all four can be enabled at the same time.
### Schedule (cron)
@@ -192,9 +193,43 @@ Two platform limits are fixed and not configurable:
The similarity comparison requires the account's AIOps capability and a Pro or higher subscription. If AIOps is off or the edition doesn't qualify, no comparison runs, and every incident starts its own run.
+### War room created
+
+Add the **War room created** trigger when you want AI SRE in the room as soon as an incident gets a war room. The trigger registers a subscription with the On-call side, and only war-room creation events matching the selected channels and severities start a run.
+
+
+
+ Click the **War room created** card in "Triggers". The form expands channel and severity conditions; severity is preselected as `Critical`.
+
+
+ Select the channels to watch in the **Channel** dropdown. Personal-scope rules can select visible account channels; team-scope rules narrow the channel list to the selected team. When this trigger is enabled, at least one channel is required.
+
+
+ Select one or more severities from `Critical`, `Warning`, and `Info`. When this trigger is enabled, at least one severity is required.
+
+
+
+
+This run's session is created in the war room's **IM group chat**, not in the console — the trigger card states "The session is created in the IM group chat." and adds a platform caveat: due to platform limits, this may not apply to WeCom and DingTalk integrations.
+
+
+If you create or update a rule through the API, use these fields:
+
+| Field | Type | Notes |
+|---|---|---|
+| `war_room_trigger_enabled` | boolean | Whether the war-room-created trigger is enabled. |
+| `war_room_channel_ids` | int64[] | Channel IDs to watch. Creating or enabling this trigger requires at least one valid ID. |
+| `war_room_severities` | string[] | Severities to watch. Supported values are `Critical`, `Warning`, and `Info`; creating or enabling this trigger requires at least one value. |
+
+When a matching war room is created, the system creates a run with `trigger_kind: "war_room_created"` and passes context such as `incident_id`, `channel_id`, and `severity` into the session. This run does not open a new console session: it runs an analysis directly in the war-room group, and the conclusion is posted back into that group. Under one trigger, a single incident starts only one run — a repeated event does not open a second session.
+
+**Environment**: this trigger does not use the rule's **Environment** — an analysis in the war room uses the execution environment already chosen for that group. When the war room is a rule's only trigger, the form hides the environment picker and only says "Analysis in the war room uses the execution environment already chosen for that group. This rule does not pick one." When the rule also enables the schedule / API / incident triggers, the picker stays and shows "Schedule, API, and incident triggers use the execution environment chosen here. The war room trigger uses the group's execution environment and does not change that choice."
+
+The preset template **War room initial analysis** (template key `war_room_initial_analysis`, category **Incident Response**) prefills this trigger and the `Critical` severity; the channels are not prefilled, so you pick them yourself.
+
## Run history
-Every rule keeps its run history. Click a rule row to open its detail page (`/ai-sre/automations/:ruleId`): the left column shows **Configuration** and the right column shows **Run History**. The **Run now** button at the top of the right column triggers a run directly.
+Every rule keeps its run history. Click a rule row to open its detail page (`/ai-sre/automations/:ruleId`): the left column shows **Configuration** and the right column shows **Run History**. The **Run now** button at the top of the right column triggers a run directly. That button does not appear when **War room created** is the rule's only trigger — those runs happen in the IM group, so the rule has no console run.
Run history is shown as a table with these columns:
@@ -203,7 +238,8 @@ Run history is shown as a table with these columns:
| Name | The title of the run's hidden session (`session_name`), or the session ID (`session_id`) if it can't be resolved. A run merged into another analysis has no session of its own, so this shows its incident (`# `) and, on the line below, the analysis it joined |
| Started at | The start time of the run |
| Duration | How long the run took |
-| Triggers | The trigger type of the run, such as `Schedule`, `HTTP POST`, `On-call incident`, or `Run manually` |
+| Triggers | The trigger type of the run, such as `Schedule`, `HTTP POST`, `On-call incident`, `Run manually`, or `War room created` (war_room_created) |
+| Where it ran | Where the run happened: `IM` (the session is in the IM group, as for a war-room-created run) or `Web console` (a hidden session in the console). The API field is `execution_place`, with values `im` / `web_console`; when a record does not carry it, a war-room-created run reads `IM` and every other run reads `Web console` |
| Status | The status of the run (see the table below) |
Run status values:
@@ -223,11 +259,11 @@ Three filters are available above the table:
- **Time range**: defaults to the **last 30 days**, adjustable, with a maximum span of **180 days**.
- **Status**: filter by the run statuses above, or choose **All statuses**.
-- **Trigger type**: choose from `All trigger types` / `Run manually` / `Schedule` / `HTTP POST` / `On-call incident`.
+- **Trigger type**: choose from `All trigger types` / `Run manually` / `Schedule` / `HTTP POST` / `On-call incident` / `War room created`.
-Run records returned by the API also include `trigger_kind`, which can be `schedule`, `manual`, `http_post`, `oncall_incident`, or `debug`. `manual` means the run was started through the run-now API, and `oncall_incident` means it was started by a matching On-call incident event. A run merged into another analysis has no `session_id` of its own. Instead, `joined_session_id` holds that analysis's session ID and `joined_session_name` holds its session name. If both are empty, the run has its own hidden session.
+Run records returned by the API also include `trigger_kind`, which can be `schedule`, `manual`, `http_post`, `oncall_incident`, `war_room_created`, or `debug`. `manual` means the run was started through the run-now API, `oncall_incident` means it was started by a matching On-call incident event, and `war_room_created` means it was started by the war-room-created trigger (its session is in the IM group). A run merged into another analysis has no `session_id` of its own. Instead, `joined_session_id` holds that analysis's session ID and `joined_session_name` holds its session name. If both are empty, the run has its own hidden session.
-Click a row to jump to the chat page of the hidden session for that run, where you can view the full messages, tool calls, and artifacts of that run. A run merged into another analysis has no session of its own, so clicking it opens the analysis that took over the incident.
+Click a row to jump to the chat page of the hidden session for that run, where you can view the full messages, tool calls, and artifacts of that run. A run that happened in IM (`execution_place=im`, or one started by `war_room_created`) does not navigate; it shows the message **This analysis is in IM. Open IM to view it.** — you read that analysis in the IM group. A run merged into another analysis has no session of its own, so clicking it opens the analysis that took over the incident.
### The reason line on an unsuccessful run
@@ -257,7 +293,7 @@ Each rule offers a set of actions in the **Actions** column:
| Action | Notes |
|---|---|
| Enable / Disable | An inline switch. When disabled, the rule is kept but no longer triggers; disabling does not delete existing run history. |
-| Run now | Starts one real run manually from the rule row. The action performs preflight checks first, then creates a hidden session for the run. Manual runs are limited to one per rule per minute. |
+| Run now | Starts one real run manually from the rule row. The action performs preflight checks first, then creates a hidden session for the run. Manual runs are limited to one per rule per minute. When **War room created** is the rule's only trigger, neither the list nor the detail page offers this action — such a rule produces no console run, and calling the run-now API returns an error. |
Clicking anywhere on the rule row opens its detail page, where you can edit the configuration, delete the rule, and view its run history (see "Run History" above).
@@ -277,6 +313,7 @@ Automation rules share the same two-level scope model as the other resources und
| Edit / manage (personal rules) | Only the creator can view and manage a personal rule. Account Owners and admins cannot view or manage other members' personal rules. |
| HTTP POST trigger | When initiating a real run through the trigger URL, authorization is only the trigger's Bearer Token. Any external system holding that Token can trigger the rule, and the run creates a hidden session under the rule's personal or team scope. |
| On-call incident trigger | Started by a registered incident subscription, not by an HTTP POST Bearer token. The run still creates a hidden session under the rule's personal or team scope. |
+| War room created trigger | Started by a registered war-room-created subscription, not by an HTTP POST Bearer token. The session is created in the war room's IM group rather than the console, and the run still belongs to the rule's personal or team scope. |
<Note>
The account Owner / admins can see other members' personal rules in the list (see "Visibility / list" above), but they can't open the detail page. The "Edit / manage" permission has no Owner / admin exemption on personal rules, the same as on team rules.
diff --git a/en/ai-sre/im.mdx b/en/ai-sre/im.mdx
index 692e7666d..60c8f4b48 100644
--- a/en/ai-sre/im.mdx
+++ b/en/ai-sre/im.mdx
@@ -1,6 +1,6 @@
---
title: IM platform
-description: AI SRE is IM-native — mention it in a Slack, Lark, DingTalk, or WeCom group or DM to start or continue an investigation; it replies in-thread. When a war room is opened for an incident, it can run an automatic preliminary diagnosis based on the integration settings and post the findings back.
+description: AI SRE is IM-native — mention it in a Slack, Lark, DingTalk, or WeCom group or DM to start or continue an investigation; it replies in-thread. When a war room is opened for an incident, an automation rule triggered by war-room creation can run a preliminary diagnosis and post the findings back.
keywords: ["AI SRE", "IM", "Slack", "Lark", "DingTalk", "WeCom", "war room", "@mention", "incident collaboration"]
sidebarTitle: IM platform
---
@@ -18,7 +18,7 @@ AI SRE's IM integration has two trigger modes:
**@mention AI SRE** in a group chat or DM and describe the problem to start or continue an investigation. It replies **in-thread**, and the conversation context is tied to that IM session.
</Card>
<Card title="War Room Auto-Diagnosis" icon="people-group">
- When someone opens an IM war room for an incident, AI SRE runs a preliminary diagnosis and posts the findings to the war room. This happens when the integration keeps **Automatically start AI incident analysis** on, which is the default. No one needs to summon it.
+ When someone opens an IM war room for an incident, AI SRE runs a preliminary diagnosis and posts the findings to the war room if the account has an enabled **War room created** automation rule that the incident's channel and severity match. No one needs to summon it.
</Card>
</CardGroup>
@@ -26,12 +26,12 @@ AI SRE's IM integration has two trigger modes:
AI SRE's IM interaction covers four major platforms. Each platform supports inbound @mentions (webhook), historical message reads, and outbound replies:
-| Platform | Group @mention | Direct message (DM) | Processing receipt | War room auto-diagnosis |
-| --- | --- | --- | --- | --- |
-| Slack | ✅ | ✅ | ✅ Emoji (plus a native "is working on it" status) | ✅ |
-| Lark / Feishu | ✅ | ✅ | ✅ Emoji | ✅ |
-| DingTalk | ✅ | ✅ | ✅ Built-in emoji | ✅ |
-| WeCom | ✅ | ✅ | ✅ Placeholder message | ✅ |
+| Platform | Group @mention | Direct message (DM) | Processing receipt |
+| --- | --- | --- | --- |
+| Slack | ✅ | ✅ | ✅ Emoji (plus a native "is working on it" status) |
+| Lark / Feishu | ✅ | ✅ | ✅ Emoji |
+| DingTalk | ✅ | ✅ | ✅ Built-in emoji |
+| WeCom | ✅ | ✅ | ✅ Placeholder message |
A "processing receipt" is the immediate signal the bot gives once it has your message; how it looks on each platform is described under [Processing Receipt](#processing-receipt).
@@ -41,9 +41,8 @@ IM interaction requires that you have already connected the corresponding platfo
## AI SRE settings in IM integrations
-Open the corresponding IM integration under **On-call → Integration Center → Integration List → Instant Messaging** and configure its AI SRE behavior under **Enhanced features**. The following switches are on by default:
+Open the corresponding IM integration under **On-call → Integration Center → Integration List → Instant Messaging** and configure its AI SRE behavior under **Enhanced features**. Both switches below are on by default:
-- **Automatically start AI incident analysis**: available after you enable War Room. When the integration creates a war room, AI SRE starts one preliminary diagnosis and posts the result back to the room.
- **Allow AI SRE conversations in IM**: available without enabling War Room. It controls both entry points — **group @mentions** and **direct chats with the bot**; in Slack it also controls the `/fd` command. Turning it off makes group @mentions and direct chats with the bot (and, in Slack, `/fd`) silent. In WeCom's Third-party App mode, only direct chats with the bot are available; group @mentions require Custom App Integration mode.
- **Use thread replies in normal group chats**: available only for Feishu/Lark and Slack. When enabled, each normal-group thread has an independent session; War Rooms still receive replies directly in the group.
@@ -104,20 +103,22 @@ When a reply is too long, AI SRE trims it or publishes the detailed evidence as
## War room auto-diagnosis
-When you open a **war room** for an incident in IM, AI SRE steps in automatically if the integration keeps **Automatically start AI incident analysis** on. No one needs to @mention it:
+Whether AI SRE steps into a war room on its own is decided by the account's **War room created** automation rules, not by a switch on the IM integration. Creating a war room only publishes a creation event; it starts no analysis by itself, so **a matching rule is what makes the diagnosis run**. No one needs to @mention it, but you do need a rule in place:
<Steps>
<Step title="Create the war room">
Create a war room (Lark / DingTalk / WeCom / Slack group) as part of the incident collaboration workflow.
</Step>
- <Step title="Trigger diagnosis in the background">
- Once the war room is created, the platform triggers a preliminary diagnosis as a **non-blocking background task**, so AI SRE enters the investigation with the full context of that incident.
+ <Step title="Match a war-room-created rule">
+ The platform matches the new war room against the account's enabled **War room created** rules: the incident's **channel** must be in the rule's list and the incident's **severity** must match the rule. Both have to hold before a run starts. With no matching rule, no analysis is produced.
</Step>
<Step title="Post the findings">
- When the diagnosis is complete, AI SRE sends the analysis results as a message back to the war room. Before anyone has started investigating manually, the first-cut analysis is already in the group.
+ The run is carried on that war room's IM group (no console session is created). AI SRE investigates with the incident's context and posts its findings back to the war room. Before anyone has started investigating manually, the first-cut analysis is already in the group.
</Step>
</Steps>
+For which fields the trigger card asks for, and how to create the rule, see [Automations · War room created](/en/ai-sre/automations#war-room-created).
+
<Note>
War room auto-diagnosis is bound to the incident context. When the investigation begins, the platform attaches the `incident_id` to the run, so AI SRE can read the incident details, timeline, and recent changes. For details on how incidents / war rooms interact with A2A, see [Agent · Incident & War Room Integration](/en/ai-sre/agents#incident-and-war-room-integration).
</Note>
diff --git a/en/ai-sre/overview.mdx b/en/ai-sre/overview.mdx
index e9e288faa..3dc2a8cb0 100644
--- a/en/ai-sre/overview.mdx
+++ b/en/ai-sre/overview.mdx
@@ -38,7 +38,7 @@ AI SRE is more than a chat box in the console — it covers multiple collaborati
No context switching needed — in Slack, Feishu, DingTalk, or WeCom group chats or direct messages, **@ AI SRE** to start or continue an investigation. It replies **in-thread** so all team members stay in the loop. See [IM Integration](/en/ai-sre/im).
</Card>
<Card title="Automatic War Room Diagnosis" icon="people-group">
- When someone opens a war room for an incident, AI SRE **automatically runs an initial diagnostic** and posts the conclusion to the war room. When your team starts investigating, a first-pass analysis is already in the channel.
+ When someone opens a war room for an incident and an enabled [automation rule](/en/ai-sre/automations) with the **War room created** trigger matches it, AI SRE **automatically runs an initial diagnostic** and posts the conclusion to the war room. When your team starts investigating, a first-pass analysis is already in the channel.
</Card>
<Card title="Usage Insights" icon="gauge-high">
Use [`/insight`](/en/ai-sre/insight) to review the past 30 days of sessions, quantify where you're spending time, identify missing runbooks and repeatedly copy-pasted context, and receive actionable improvement suggestions.
@@ -96,7 +96,7 @@ AI SRE is built around "conversational troubleshooting + knowledge accumulation
Collaborate with the agent session by session. A session handles your messages one at a time, with streaming output, cancellation at any time, automatic context compaction for long conversations, and one-click launch from an incident.
</Card>
<Card title="IM Platform" icon="comment-dots" href="/en/ai-sre/im">
- @ the agent in Slack / Feishu / DingTalk / WeCom to start or continue an investigation, and receive automatic initial diagnostics in incident war rooms.
+ @ the agent in Slack / Feishu / DingTalk / WeCom to start or continue an investigation, and receive rule-driven initial diagnostics in incident war rooms.
</Card>
<Card title="Skills" icon="wrench" href="/en/ai-sre/skills">
Skill packages that the agent can invoke, encapsulating reusable troubleshooting workflows. Scope can be set to Shared (account-level) or Team; once enabled, they are loaded on demand during sessions.
diff --git a/en/ai-sre/quickstart.mdx b/en/ai-sre/quickstart.mdx
index c56a234a6..0f2e480eb 100644
--- a/en/ai-sre/quickstart.mdx
+++ b/en/ai-sre/quickstart.mdx
@@ -34,7 +34,7 @@ For work that shouldn't need a human watching it — scheduled inspections, week
### IM (@ mentions + automatic war room diagnosis)
-Where incidents actually happen. In any Slack, Feishu, DingTalk, or WeCom group with the bot connected, **@ AI SRE** to start or continue an investigation — it replies in-thread. Open a war room for an incident and AI SRE automatically runs an initial diagnosis and posts the conclusion back. → See [IM](/en/ai-sre/im)
+Where incidents actually happen. In any Slack, Feishu, DingTalk, or WeCom group with the bot connected, **@ AI SRE** to start or continue an investigation — it replies in-thread. Open a war room for an incident and, when an [automation rule](/en/ai-sre/automations) with the **War room created** trigger matches it, AI SRE automatically runs an initial diagnosis and posts the conclusion back. → See [IM](/en/ai-sre/im)
## Your first investigation (~5 min)
@@ -80,7 +80,7 @@ Your first investigation is the starting point. From here, you can make analysis
Once manual investigations feel routine, make them the default. Go to **AI SRE → Automations** and create a rule from the built-in **On-call Incident Analysis** template. Enable the **On-call incident** trigger card, and pick the channels and severities to watch. From then on, every matching new incident gets an automatic investigation. AI SRE writes one summary comment back to the incident, with the conclusion first and the full session link at the end. The incident's existing notification channels deliver it, so responders see the first analysis in IM. Configuration details: [Automations · On-call Incident Trigger](/en/ai-sre/automations#on-call-incident-trigger).
-This is independent of war room auto-diagnosis: this path fires for every matching new incident and writes back to the incident itself. War room diagnosis runs when you open a war room for an incident and posts into the war room group (see [IM](/en/ai-sre/im)).
+This is independent of war room auto-diagnosis: this path fires for every matching new incident and writes back to the incident itself. War room diagnosis is driven by an automation rule with the **War room created** trigger — it runs when you open a war room for an incident and the rule matches, and posts into the war room group (see [IM](/en/ai-sre/im)).
### Build team knowledge
diff --git a/en/changelog/changelog.mdx b/en/changelog/changelog.mdx
index 0000b1ec0..741fff380 100644
--- a/en/changelog/changelog.mdx
+++ b/en/changelog/changelog.mdx
@@ -4,6 +4,23 @@ description: "This page documents important updates and feature releases for Fla
keywords: ["Changelog", "Product Release", "Feature Updates", "Flashduty", "Version History"]
---
+<Update label="2026-10-13" description="🤖 AI SRE automations gain a war room created trigger, alert-rule related and recovery queries accept Go templates">
+
+### AI SRE automations gain a War room created trigger
+
+Automations gain a fourth trigger alongside **Schedule**, **Call via API** and **On-call incident**: **War room created** (`trigger_kind` `war_room_created`). Pick the channels and severities to watch (severity is preselected as `Critical`), and a run starts when a war room of a matching severity is created in one of those channels — the run's session lives in the war room's IM group chat, not in the console, and the conclusion is posted back into that group. The preset template **War room initial analysis** (template key `war_room_initial_analysis`, category **Incident Response**) prefills this trigger and the `Critical` severity, but not the channels — you pick those yourself.
+
+Alongside this, the **Enhanced Features** form of an IM integration no longer carries the **Automatically start AI incident analysis** switch: the analysis that follows a war room creation is now driven by an automation rule, so to have AI SRE step in as soon as a war room appears, enable a rule that has the **War room created** trigger. See [AI SRE automations](/en/ai-sre/automations).
+
+### Alert rules: related and recovery queries accept Go templates
+
+The expressions of a **Recovery Query** and a **Related Query** now accept the Go template syntax `{{ $labels.<label_name> }}` as an alternative to `${label_name}`, rendered **per alert instance** — every instance is rendered once with its own labels, so one rule produces a different query string for each instance. The two syntaxes are either/or: an expression containing both `${...}` and `{{...}}` is rejected on save, while separate expressions are independent and may each pick a different one. A template sees only `$labels`, the current alert instance's labels, and its function set is limited to `len`, `index`, `regexQuoteMeta`, `replace`, the comparison and logic functions (`eq`, `ne`, `lt`, `le`, `gt`, `ge`, `and`, `or`, `not`) plus `if`/`else`; formatting functions such as `printf`, the Sprig set, `range` loops and `define`/`block` are all rejected. Main queries do **not** support templates and are unaffected by these rules.
+
+Self-hosted deployments should note the version requirement: a Go template needs **every** registered monit-edge in the clusters of the data sources matched by the rule to be `v0.75.4` or later, and saving is rejected otherwise; the `${label_name}` syntax is not subject to it. See [Alert rules · Prometheus](/en/monitors/alert-rules/prometheus).
+
+</Update>
+
+
<Update label="2026-10-09" description="📊 Dashboard built-in time variables and display time zone, RUM Explorer analytics, OAuth for MCP Server and the Go SDK">
### Dashboards: built-in time variables and display time zone
diff --git a/en/developer/cli.mdx b/en/developer/cli.mdx
index 5e08a17a5..1c767853d 100644
--- a/en/developer/cli.mdx
+++ b/en/developer/cli.mdx
@@ -662,6 +662,8 @@ flashduty monit dashboard-runtime-queries-resolve <panel-id> [<id2>...] # Resol
Panel runtime and variable resolution take their time window and variable selections as JSON objects in `--data` (time uses millisecond `from_ms` / `to_ms` timestamps). `dashboard-panel-preview` and `dashboard-runtime-variables-preview` need a `context`: `kind: existing` with a `dashboard_id` targets a stored dashboard, `kind: new` with a `folder_id` targets a folder that does not hold one yet.
+`dashboard-runtime-queries-resolve` takes two further flags that shape the result: `--max-data-points` (int, 2–5000; both the downsampling target and what decides the step the built-in time variables render with — omit it or send `null` for the server default of 100) and `--preserve-builtin-variables` (bool, off by default): when set, the **built-in time variables** stay verbatim in the resolved expressions so a caller with its own execution window can render them, while user variables are still resolved. The sibling commands `dashboard-panel-run` and `dashboard-panel-preview` already carried `--max-data-points`, likewise a 2–5000 downsampling target.
+
#### `prometheus-api-v1-label-{label_name}-values` — Query Prometheus label values
`GET /monit/prometheus/api/v1/label/{label_name}/values` (operationId `monit-prometheus-read-label-values`) carries a path parameter, so it is excluded from code generation and provided by a hand-written command. The command name is derived from the API path: the `monit` group plus the remaining path segments joined by hyphens. It appears under `flashduty monit --help` but is hard to guess, so use it as written here:
@@ -690,7 +692,7 @@ flashduty alert get <alert_id> # Get full detail of one alert; detail is an
flashduty alert-event list [flags] # List alert events (default: last 1h)
```
-Common filter flags for both `list` commands: `--severity` (`Critical,Warning,Info`), `--channel` (comma-separated channel IDs), `--integration` (comma-separated integration IDs), `--since`/`--until`, `--limit` (max 100), `--page`. `alert-event list` also takes `--integration-type`, which filters by comma-separated **plugin keys** (for example, `AliCloud,Prometheus`) — note these are plugin keys, not integration IDs; use `--integration` to filter by integration ID.
+Common filter flags for both `list` commands: `--severity` (`Critical,Warning,Info`), `--channel` (comma-separated channel IDs), `--integration` (comma-separated integration IDs), `--since`/`--until`, `--limit` (max 100), `--page`. The `--since`/`--until` window must span under 31 days, as on `incident list` and `change list`. `alert-event list` also takes `--integration-type`, which filters by comma-separated **plugin keys** (for example, `AliCloud,Prometheus`) — note these are plugin keys, not integration IDs; use `--integration` to filter by integration ID.
`alert list` also takes these flags:
@@ -733,7 +735,7 @@ Common `create` flags:
`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 is immutable after creation, so `update` exposes no scope flag.
-`runs` supports `--status` (`queued`/`running`/`retrying`/`succeeded`/`partial`/`failed`/`skipped`/`abandoned`), `--trigger-kind` (`schedule`/`debug`/`http_post`), `--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).
+`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).
<Warning>
**Timezone semantics**: `--at` and `--cron-expr` are interpreted as local wall-clock time in the **rule's timezone**. When `create` omits `--timezone`, the server picks the rule's timezone: the caller's member timezone, then the account timezone, then `Asia/Shanghai`. Pass an IANA name to pin another one (for example, `--timezone Asia/Shanghai`); a timezone the server cannot load is rejected. When `update` omits `--timezone`, the stored timezone stays, including a legacy empty string; an explicit empty `--timezone ""` is sent and stored as UTC, not the account default. Pass the user's local time directly — do **not** convert it to UTC. `update` recalculates the next fire immediately, so read `schedule_next_fire_at_ms` from the response.
@@ -783,6 +785,8 @@ flashduty safari --help # AI SRE generated commands
flashduty alert --help # Alert-related generated commands
```
+If the body you pass in `--data` carries a field the installed CLI version's SDK has no field for, that field is **not** sent: once the request body is bound, the CLI prints `warning: --data fields not sent, unknown to this CLI version: <field paths>` on stderr (paths are dotted, array elements end in `[]`, for example `labels.k.note` or `targets[].purpose`; several are comma-separated). The call itself still succeeds and stdout is unaffected — the warning means the fields you sent are newer than the installed CLI, so a script that depends on them taking effect should upgrade the CLI first.
+
Time-window flags on generated commands (`--start-time` / `--end-time`) accept the same formats as the curated commands:
- Relative durations such as `7d` or `24h`, meaning "now minus duration".
diff --git a/en/developer/go-sdk.mdx b/en/developer/go-sdk.mdx
index d6e5f4228..10ab8bb0c 100644
--- a/en/developer/go-sdk.mdx
+++ b/en/developer/go-sdk.mdx
@@ -84,7 +84,7 @@ Every call returns three values:
| Return value | Type | Description |
|--------|------|------|
-| data | `*T` | The endpoint's typed response body (for example, `*ListIncidentsResponse`); `nil` on failure |
+| data | `*T` | The endpoint's typed response body (for example, `*IncidentListResponse`); `nil` on failure |
| `*Response` | `*flashduty.Response` | Wraps `*http.Response` and carries envelope metadata such as `RequestID` and pagination |
| `error` | `error` | `*ErrorResponse` on failure, `*RateLimitError` on 429 |
@@ -138,7 +138,7 @@ Access tokens are issued by the Flashduty OAuth authorization server, whose addr
## Services and methods
-Endpoints are grouped by service and hang off the client: the call convention is uniformly `client.<Service>.<Method>(ctx, req)`, returning `(*T, *Response, error)`. For example, `client.Incidents.List(ctx, req)` or `client.Sessions.Info(ctx, req)`.
+Endpoints are grouped by service and hang off the client: the call convention is uniformly `client.<Service>.<Method>(ctx, req)`, returning `(*T, *Response, error)`. For example, `client.Incidents.List(ctx, req)` or `client.Sessions.ReadInfo(ctx, req)`.
| Service field | Description |
|----------|------|
@@ -155,8 +155,10 @@ Endpoints are grouped by service and hang off the client: the call convention is
| `client.Account` | Account |
| `client.AuditLogs` | Audit logs |
| `client.AlertRules` | Alert rules |
+| `client.RuleFolders` | Rule folders; `List` lists every monitor folder the caller can read (`POST /monit/folder/list`) |
| `client.AlertEnrichment` | Alert enrichment |
| `client.DataSources` | Data sources |
+| `client.Dashboards` | Dashboards; panel preview and run, panel query resolution (`QueryReadResolve`), variable resolution, plus dashboard read/write, move/restore, and revision history |
| `client.Integrations` | Integrations |
| `client.ImIntegrations` | IM integrations |
| `client.NotificationTemplates` | Notification templates |
diff --git a/en/monitors/alert-rules/clickhouse.mdx b/en/monitors/alert-rules/clickhouse.mdx
index d9c677191..8af11384f 100644
--- a/en/monitors/alert-rules/clickhouse.mdx
+++ b/en/monitors/alert-rules/clickhouse.mdx
@@ -47,7 +47,7 @@ Monitors distinguishes alert objects by their label fields and evaluates thresho
|------|------|
| **Auto Recovery** | When values no longer satisfy any alert threshold, automatically generates recovery event |
| **Specific Recovery Condition** | Configure recovery expression (for example, `$A.error_cnt < 5`) |
-| **Recovery Query** | Independent SQL for recovery evaluation, supports `${label_name}` variables |
+| **Recovery Query** | Independent SQL for recovery evaluation, supports `${label_name}` variables; the Go template `{{ $labels.<label_name> }}` is also accepted and requires monit-edge `v0.75.4` or later |
| **Manual Close** | Keep the alert active until it is closed manually |
## Data exists mode
diff --git a/en/monitors/alert-rules/elasticsearch.mdx b/en/monitors/alert-rules/elasticsearch.mdx
index f03465736..95d1d08b6 100644
--- a/en/monitors/alert-rules/elasticsearch.mdx
+++ b/en/monitors/alert-rules/elasticsearch.mdx
@@ -57,7 +57,7 @@ Label field combination uniquely identifies an alert object. Query results canno
|------|------|
| **Auto Recovery** | When values no longer satisfy any alert threshold, automatically generates recovery event |
| **Specific Recovery Condition** | Configure recovery expression (for example, `$A.error_cnt < 5`) to prevent alert flapping |
-| **Recovery Query** | Write independent SQL for recovery evaluation, supports `${label_name}` variables |
+| **Recovery Query** | Write independent SQL for recovery evaluation, supports `${label_name}` variables; the Go template `{{ $labels.<label_name> }}` is also accepted and requires monit-edge `v0.75.4` or later |
| **Manual Close** | Keep the alert active until it is closed manually |
<Accordion title="Recovery Query Example">
diff --git a/en/monitors/alert-rules/mysql.mdx b/en/monitors/alert-rules/mysql.mdx
index 772d18540..d86a211b7 100644
--- a/en/monitors/alert-rules/mysql.mdx
+++ b/en/monitors/alert-rules/mysql.mdx
@@ -13,6 +13,8 @@ Monitors supports using standard SQL syntax to query MySQL and trigger alerts ba
| **Field Processing** | All field names are automatically converted to lowercase; please use lowercase letters when configuring |
| **Time Processing** | Recommended to use `now()`, `unix_timestamp()` and other functions for time filtering |
+MySQL alert SQL must be fully determined when saved: the validator rejects any runtime variable in a statement (neither the `${label_name}` placeholder nor the `{{ $labels.<label_name> }}` Go template is accepted, and the same applies to related queries and recovery queries), so such rules cannot be rendered per alert instance.
+
## Threshold evaluation mode
This mode is suitable for scenarios requiring threshold comparison on aggregated values.
@@ -47,7 +49,7 @@ Monitors distinguishes alert objects by their label fields and evaluates thresho
|------|------|
| **Auto Recovery** | When values no longer satisfy any alert threshold, automatically generates recovery event |
| **Specific Recovery Condition** | Configure recovery expression (for example, `$A.error_cnt < 5`) |
-| **Recovery Query** | Independent SQL for recovery evaluation, supports `${label_name}` variables |
+| **Recovery Query** | Independent SQL for recovery evaluation; the SQL must be fully determined and cannot use runtime variables |
| **Manual Close** | Keep the alert active until it is closed manually |
## Data exists mode
diff --git a/en/monitors/alert-rules/oracle.mdx b/en/monitors/alert-rules/oracle.mdx
index 58a7b101a..844a0b75a 100644
--- a/en/monitors/alert-rules/oracle.mdx
+++ b/en/monitors/alert-rules/oracle.mdx
@@ -47,7 +47,7 @@ Monitors distinguishes alert objects by their label fields and evaluates thresho
|------|------|
| **Auto Recovery** | When values no longer satisfy any alert threshold, automatically generates recovery event |
| **Specific Recovery Condition** | Configure recovery expression (for example, `$A.error_cnt < 5`) |
-| **Recovery Query** | Independent SQL for recovery evaluation, supports `${label_name}` variables |
+| **Recovery Query** | Independent SQL for recovery evaluation, supports `${label_name}` variables; the Go template `{{ $labels.<label_name> }}` is also accepted and requires monit-edge `v0.75.4` or later |
| **Manual Close** | Keep the alert active until it is closed manually |
## Data exists mode
diff --git a/en/monitors/alert-rules/postgres.mdx b/en/monitors/alert-rules/postgres.mdx
index 7f3335162..4196d8fed 100644
--- a/en/monitors/alert-rules/postgres.mdx
+++ b/en/monitors/alert-rules/postgres.mdx
@@ -47,7 +47,7 @@ Monitors distinguishes alert objects by their label fields and evaluates thresho
|------|------|
| **Auto Recovery** | When values no longer satisfy any alert threshold, automatically generates recovery event |
| **Specific Recovery Condition** | Configure recovery expression (for example, `$A.error_cnt < 5`) |
-| **Recovery Query** | Independent SQL for recovery evaluation, supports `${label_name}` variables |
+| **Recovery Query** | Independent SQL for recovery evaluation, supports `${label_name}` variables; the Go template `{{ $labels.<label_name> }}` is also accepted and requires monit-edge `v0.75.4` or later |
| **Manual Close** | Keep the alert active until it is closed manually |
## Data exists mode
diff --git a/en/monitors/alert-rules/prometheus.mdx b/en/monitors/alert-rules/prometheus.mdx
index 4d44d0e5f..c8ddd54e7 100644
--- a/en/monitors/alert-rules/prometheus.mdx
+++ b/en/monitors/alert-rules/prometheus.mdx
@@ -193,10 +193,45 @@ up{instance="${instance}", job="${job}"} == 1
When the alert engine executes, it will replace `${instance}` with `host-1` and `${job}` with `node`, that is, the specific values in the alert event labels.
+#### Go template variables
+
+Besides `${label_name}`, the expressions of **Recovery Query** and **Related Query** also accept the Go template syntax `{{ $labels.<label_name> }}`. A single expression can only use one of the two: if an expression contains both `${...}` and `{{...}`, saving is rejected with `query expression mixes ${label} placeholders with Go template; use {{ $labels.name }} only`. Different expressions are independent of each other and may each pick a different syntax.
+
+Templates are supported in the following three field kinds, and **not in main queries** — the alert engine never renders labels in main queries, so a `{{ ... }}` written there is treated as query text itself (in PromQL it fails save-time validation as invalid syntax):
+
+- **Related Queries**: every related query statement configured on the rule.
+- **Threshold recovery query**: in threshold mode, the recovery query used when the recovery method is "query statement".
+- **Data exists / data missing recovery query**: in those modes, the recovery query used when the recovery method is "query statement".
+
+The template context is only `$labels` (the labels of the current alert instance): recovery and related queries run before the alert event is assembled, so `$values`, `$relates` and friends are not available there. The only available functions are `len`, `index`, `regexQuoteMeta`, `replace`, `eq`, `ne`, `lt`, `le`, `gt`, `ge`, `and`, `or` and `not`, plus the `if`/`else` control structure; formatting functions such as `printf`, the Sprig function set, `range` loops, `define`/`block` and the `.`/`.Field` form are all rejected (the `.` form fails with `use $labels to access instance labels`).
+
+A label name that itself contains a dot (such as `service.name`) cannot be written as `$labels.service.name`; use `index $labels "service.name"` instead.
+
+Assuming an alert instance carries `host="host-1"`, the recovery query can be written like this:
+
+```
+up{host=~"{{ regexQuoteMeta $labels.host }}"} == 1
+```
+
+which renders to `up{host=~"host-1"} == 1`. The value a template produces must be quoted by the expression itself: in the example the `"` characters belong to PromQL strings and `{{ ... }}` only produces the value.
+
+<Warning>
+Go templates require monit-edge `v0.75.4` or later. Save-time validation checks **every** registered monit-edge instance in the clusters of the data sources matched by the rule: if any instance is older than `v0.75.4`, saving is rejected, with an error that starts with `Go template relate or recovery queries require` and names `v0.75.4` as the required version. The `${label_name}` syntax is not subject to this version requirement.
+</Warning>
+
+#### Rendering timing and failure handling
+
+monit-edge renders templates **per alert instance**: each instance is rendered once with its own labels, so the same rule yields different query statements for different instances.
+
+**The expression owns its quoting and escaping.** Template output is inserted verbatim and is not escaped — `{{ $labels.host }}` produces the label value alone, so the quotes must be written by the expression itself (as in the `host=~"{{ ... }}"` above); when a label value may contain quotes or other special characters, handle it yourself with `regexQuoteMeta` or `replace`. This differs from `${label_name}`: in a recovery query the engine escapes `${label_name}` and places it inside the query's string literal, while in a related query `${label_name}` is substituted verbatim and an unmatched placeholder is left as is.
+
+**Render failures**: when a related query fails to render (for example it references a label that is not present on the alert event, or the template syntax is invalid), that related query is skipped while the remaining related queries still run, and the engine records a `render related query` rule-context error carrying `query_ref="<related query name>"`. A recovery query expression that contains `{{` is treated as "has variables" and rendered per instance instead of being executed once as a static expression.
+
### Related query (enrichment)
To enrich alert notification content, you can configure "Related Query". Related queries don't participate in alert evaluation, only used to get additional information.
- **Scenario**: During CPU alert, simultaneously query that machine's `mem_usage_percent` load situation, displaying it in alert details to assist troubleshooting.
-- **Variables**: Related queries support `${label_name}` variables for querying specific alert objects.
+- **Variables**: Related queries support `${label_name}` variables and the Go template `{{ $labels.<label_name> }}` (requires monit-edge `v0.75.4` or later) for querying specific alert objects; see "Labels and variables" above for the restrictions and rendering rules of both syntaxes.
+- **Render failure**: when a related query expression fails to render, that query is skipped, the remaining related queries still run, and a `render related query` rule-context error is recorded.
- **Result Display**: Related query results can be referenced in the alert rule's notes description using the `$relates` variable. You can check the detailed usage instructions for **Notes Description**.
diff --git a/en/monitors/alert-rules/sls.mdx b/en/monitors/alert-rules/sls.mdx
index 491aaaae4..2af2b59d3 100644
--- a/en/monitors/alert-rules/sls.mdx
+++ b/en/monitors/alert-rules/sls.mdx
@@ -48,7 +48,7 @@ Monitors runs the SLS query for the configured time range, distinguishes alert o
|------|------|
| **Auto Recovery** | When values no longer satisfy any alert threshold, automatically recovers |
| **Specific Recovery Condition** | Configure recovery expression (for example, `$A.error_cnt < 5`) |
-| **Recovery Query** | Independent SQL for recovery evaluation, supports `${label_name}` variables |
+| **Recovery Query** | Independent SQL for recovery evaluation, supports `${label_name}` variables; the Go template `{{ $labels.<label_name> }}` is also accepted and requires monit-edge `v0.75.4` or later |
| **Manual Close** | Keep the alert active until it is closed manually |
## Data exists mode
diff --git a/en/monitors/alert-rules/victorialogs.mdx b/en/monitors/alert-rules/victorialogs.mdx
index 0b3536bd7..d2b604289 100644
--- a/en/monitors/alert-rules/victorialogs.mdx
+++ b/en/monitors/alert-rules/victorialogs.mdx
@@ -86,7 +86,7 @@ Different threshold different level configuration examples:
|------|------|
| **Auto Recovery** | When values no longer satisfy any alert threshold, automatically generates recovery event |
| **Specific Recovery Condition** | Configure recovery expression (for example, `$A.total < 10`) to reduce flapping |
-| **Recovery Query** | Independent query for recovery evaluation, supports `${label_name}` variables |
+| **Recovery Query** | Independent query for recovery evaluation, supports `${label_name}` variables; the Go template `{{ $labels.<label_name> }}` is also accepted and requires monit-edge `v0.75.4` or later |
| **Manual Close** | Keep the alert active until it is closed manually |
## Data exists mode
diff --git a/en/on-call/advanced/war-room.mdx b/en/on-call/advanced/war-room.mdx
index 650d34dbd..0bfacde8a 100644
--- a/en/on-call/advanced/war-room.mdx
+++ b/en/on-call/advanced/war-room.mdx
@@ -147,13 +147,13 @@ Flashduty posts key incident operations (acknowledgment, closure, snooze, commen
## AI SRE
-War rooms integrate deeply with **AI SRE**: when a war room opens, AI SRE runs a first diagnosis and posts its findings to the group. You can also **@ AI SRE** in the chat to follow up or start a new investigation. See the [AI SRE introduction](/en/ai-sre) and [IM platforms](/en/ai-sre/im).
+War rooms integrate deeply with **AI SRE**: you can **@ AI SRE** in the chat to follow up or start a new investigation; and when an enabled [AI SRE automation](/en/ai-sre/automations) whose trigger is **War room created** matches the incident's channel and severity, that rule runs a first diagnosis in the group and posts its findings there as soon as the war room opens. See the [AI SRE introduction](/en/ai-sre) and [IM platforms](/en/ai-sre/im).
### AI SRE in the war room
<CardGroup cols={2}>
<Card title="Automatic first diagnosis" icon="robot">
- When a war room opens, AI SRE analyzes the incident and posts a first round of findings — before anyone has started investigating
+ When an enabled **War room created** automation matches the incident's channel and severity, it analyzes the incident and posts a first round of findings as soon as the war room opens — before anyone has started investigating
</Card>
<Card title="Follow up in chat" icon="comment-dots">
@ AI SRE in the group to start or continue an investigation; the agent replies in the thread, visible to the whole team
diff --git a/en/on-call/comparison/vs-opsgenie.mdx b/en/on-call/comparison/vs-opsgenie.mdx
index ac90aee45..d2a4a6ee4 100644
--- a/en/on-call/comparison/vs-opsgenie.mdx
+++ b/en/on-call/comparison/vs-opsgenie.mdx
@@ -124,7 +124,7 @@ Response solves "closing the loop quickly once the right person is found": a sin
| --- | --- | --- |
| **AI Summaries & Post-Mortems** | Built-in AI incident summaries and one-click AI post-mortems | No equivalent |
| **Autonomous Troubleshooting Agent** | [AI SRE](/en/ai-sre): a fully capable autonomous Agent loop connected to your real environment — cloud sandbox + self-hosted Runner executing diagnostic commands dynamically, extensible without limit through Skills, MCP, Subagents, and A2A; with an enabled Monitors data source, it can **query data sources directly through the alerting engine** (built-in monit-query Skill, no Runner needed) | No equivalent |
-| **Native IM Troubleshooting** | [Group-chat @-mentions and private-chat troubleshooting](/en/ai-sre/im) across Feishu/Lark, DingTalk, WeCom, and Slack, with automatic initial diagnosis once a war room is created | No equivalent |
+| **Native IM Troubleshooting** | [Group-chat @-mentions and private-chat troubleshooting](/en/ai-sre/im) across Feishu/Lark, DingTalk, WeCom, and Slack, with automatic initial diagnosis driven by a matching automation rule once a war room is created | No equivalent |
| **Billing** | Usage-based credits billing (1 credit = ¥1); activation is free, with gift credits each billing period | — |
### Platform & integrations
diff --git a/en/on-call/comparison/vs-pagerduty.mdx b/en/on-call/comparison/vs-pagerduty.mdx
index 6de2893d4..9eedbe699 100644
--- a/en/on-call/comparison/vs-pagerduty.mdx
+++ b/en/on-call/comparison/vs-pagerduty.mdx
@@ -158,9 +158,9 @@ The two vendors take different approaches to AI. **PagerDuty splits AI across mu
| --- | --- | --- |
| **Product Form** | Autonomous SRE Agent: conversational troubleshooting + autonomous planning and execution + knowledge accumulation | AIOps for incident noise reduction/correlation; Advance as a generative AI assistant (summaries, Q&A, post-mortem drafts); four preset AI Agents each own a slice: SRE (diagnosis + pre-configured remediation), Scribe (meeting notes), Shift (scheduling), Insights (data Q&A) |
| **Troubleshooting & Remediation** | Cloud sandbox + self-hosted [Runner (BYOC)](/en/ai-sre/environments), dynamically executing diagnostic commands and querying monitoring data and logs within your environment—**able to investigate problems it has never seen before**; with an enabled Monitors data source, it can **query data sources directly through the alerting engine** (built-in monit-query Skill, no Runner needed) | SRE Agent can automatically analyze logs/metrics and match them against historical incidents; remediation actions depend on **pre-configured** Automation Actions scripts |
-| **Native IM Collaboration** | [Group-chat @-mentions and private-chat troubleshooting](/en/ai-sre/im) across Feishu/Lark, Dingtalk, WeCom, and Slack, with **automatic initial diagnosis triggered once a war room is created** | Primarily Slack and Teams, no China-region IM support |
+| **Native IM Collaboration** | [Group-chat @-mentions and private-chat troubleshooting](/en/ai-sre/im) across Feishu/Lark, Dingtalk, WeCom, and Slack, with **automatic initial diagnosis driven by a matching automation rule once a war room is created** | Primarily Slack and Teams, no China-region IM support |
| **Code Repositories & K8s** | [GitHub/GitLab App](/en/ai-sre/apps) accesses code repositories from within the sandbox and can submit PRs/MRs/Issues; a Kubernetes App connects to clusters at the namespace level | Not found in public materials |
-| **AI Automation Tasks** | [Automations](/en/ai-sre/automations) trigger on a cron schedule, by HTTP API, or on incident events, with built-in templates for alert noise analysis, incident post-mortems, on-call insights, and more; on-call incident triggers support **similar-incident merge analysis** (incidents with similarity ≥0.9 join the in-progress analysis session) | Relies on the separate Event Orchestration and Runbook Automation product lines |
+| **AI Automation Tasks** | [Automations](/en/ai-sre/automations) trigger on a cron schedule, by HTTP API, on incident events, or when a war room is created, with built-in templates for alert noise analysis, incident post-mortems, on-call insights, and more; on-call incident triggers support **similar-incident merge analysis** (incidents with similarity ≥0.9 join the in-progress analysis session) | Relies on the separate Event Orchestration and Runbook Automation product lines |
| **Extensibility** | [Skills marketplace](/en/ai-sre/skills), [MCP external tools](/en/ai-sre/mcp), [Subagent and A2A delegation](/en/ai-sre/agents), **with no ceiling on the extension surface** | SRE Agent is limited to toggling official preset connectors (about 23, for example, Datadog, Splunk, CloudWatch) and appending prompt-style Skills; it doesn't support mounting arbitrary MCP tools to its own agents, has no subagent spawning, and cross-vendor agent collaboration is still in early access |
| **Knowledge & Memory** | [Knowledge](/en/ai-sre/knowledge) (DUTY.md + file references), [automatic memory extraction](/en/ai-sre/memory); `/init` can import existing knowledge from tools like Claude Code and Cursor | Not found in public materials |
| **AI Post-Mortems** | One-click post-mortem generation + scheduled automated post-mortems | Post-Mortems (formerly Jeli, being merged into the core product) are available from Professional up, capped at 300 per year on the Professional/Business tiers |
diff --git a/en/on-call/integration/instant-messaging/dingtalk.mdx b/en/on-call/integration/instant-messaging/dingtalk.mdx
index cac1ede99..51930bffa 100644
--- a/en/on-call/integration/instant-messaging/dingtalk.mdx
+++ b/en/on-call/integration/instant-messaging/dingtalk.mdx
@@ -201,13 +201,14 @@ Only one IM integration can have War Room enabled at a time. If another IM integ
## AI SRE controls
-Configure the following AI SRE controls under **Enhanced Features**. Both are enabled by default:
+Configure the following AI SRE control under **Enhanced Features**. It is enabled by default:
-- **Automatically start AI incident analysis**: Appears only after you enable War Room. Starts an AI incident analysis when a War Room is created successfully.
- **Allow AI SRE conversations in IM**: Available without enabling War Room. When enabled, people can @mention AI SRE in a group chat connected through this integration or start a direct conversation with the bot. When disabled, neither entry point triggers an AI SRE reply.
These controls do not take effect until AI SRE is enabled for the account.
+The automatic AI incident analysis that follows a War Room creation is no longer configured on this page: to start one when a War Room is created, add a rule in [Automations](/en/ai-sre/automations), choose the **War room created** trigger, and select the channels and severities to watch.
+
<span id="publish"></span>
## App publishing and usage
diff --git a/en/on-call/integration/instant-messaging/lark.mdx b/en/on-call/integration/instant-messaging/lark.mdx
index 4630147c7..870556769 100644
--- a/en/on-call/integration/instant-messaging/lark.mdx
+++ b/en/on-call/integration/instant-messaging/lark.mdx
@@ -140,12 +140,13 @@ Only one IM integration can have War Room enabled at a time. If another IM integ
Configure the following AI SRE controls separately under **Enhanced Features**. They are enabled by default:
-- **Automatically start AI incident analysis**: Available after you enable War Room. Starts an AI incident analysis when a War Room is created successfully.
- **Allow AI SRE conversations in IM**: Available without enabling War Room. When enabled, people can @mention AI SRE in a group chat connected through this integration or start a direct conversation with the bot. When disabled, neither entry point triggers an AI SRE reply.
- **Use thread replies in normal group chats**: Available without enabling War Room. When enabled, each normal-group thread has an independent session; War Rooms still receive replies directly in the group.
These controls do not take effect until AI SRE is enabled for the account.
+The automatic AI incident analysis that follows a War Room creation is no longer configured on this page: to start one when a War Room is created, add a rule in [Automations](/en/ai-sre/automations), choose the **War room created** trigger, and select the channels and severities to watch.
+
## Linked users
In the **Linked Users** tab of the integration detail page, you can view the linking status between team members and Feishu/Lark accounts, and quickly complete batch linking.
diff --git a/en/on-call/integration/instant-messaging/slack.mdx b/en/on-call/integration/instant-messaging/slack.mdx
index 6393bae6d..9bc67e2cd 100644
--- a/en/on-call/integration/instant-messaging/slack.mdx
+++ b/en/on-call/integration/instant-messaging/slack.mdx
@@ -33,12 +33,13 @@ After completing the previous steps, in the Flashduty On-call integration config
Configure the following AI SRE controls separately under **Enhanced Features**. They are enabled by default:
-- **Automatically start AI incident analysis**: Available after you enable War Room. Starts an AI incident analysis when a War Room is created successfully.
- **Allow AI SRE conversations in IM**: Available without enabling War Room. When enabled, people can @mention AI SRE or use `/fd` in a Slack group connected through this integration, or start a direct conversation with the bot. When disabled, none of these entry points triggers an AI SRE reply.
- **Use thread replies in normal group chats**: Available without enabling War Room. When enabled, each normal-group thread has an independent session; War Rooms still receive replies directly in the group.
These controls do not take effect until AI SRE is enabled for the account.
+The automatic AI incident analysis that follows a War Room creation is no longer configured on this page: to start one when a War Room is created, add a rule in [Automations](/en/ai-sre/automations), choose the **War room created** trigger, and select the channels and severities to watch.
+
## Linked users
In the **Linked Users** tab of the integration detail page, you can view the linking status between team members and Slack accounts, and quickly complete batch linking.
diff --git a/en/on-call/integration/instant-messaging/wecom.mdx b/en/on-call/integration/instant-messaging/wecom.mdx
index bea8f2765..ea4cafd9e 100644
--- a/en/on-call/integration/instant-messaging/wecom.mdx
+++ b/en/on-call/integration/instant-messaging/wecom.mdx
@@ -119,9 +119,8 @@ Only one IM integration can have War Room enabled at a time. If another IM integ
## AI SRE controls
-Configure the following AI SRE controls in the integration configuration page's **Enhanced Features** module. They are enabled by default:
+Configure the following AI SRE control in the integration configuration page's **Enhanced Features** module. It is enabled by default:
-- **Automatically start AI incident analysis**: Appears only after you enable War Room. Starts an AI incident analysis when a War Room is created successfully.
- **Allow AI SRE conversations in IM**: Available without enabling War Room. It controls both entry points of this integration — @ AI SRE in group chats and direct chats with the bot. When disabled, the corresponding entry point does not trigger an AI SRE reply.
The two WeCom app modes support different AI SRE entry points. **Allow AI SRE conversations in IM** is shown in both modes, and the integration detail preview also shows its status:
@@ -133,6 +132,8 @@ The two WeCom app modes support different AI SRE entry points. **Allow AI SRE co
These controls do not take effect until AI SRE is enabled for the account.
+The automatic AI incident analysis that follows a War Room creation is no longer configured on this page: to start one when a War Room is created, add a rule in [Automations](/en/ai-sre/automations), choose the **War room created** trigger, and select the channels and severities to watch.
+
## Configure the AI SRE smart robot
@mention the Smart Robot in a WeCom single chat or group chat to start an AI SRE investigation session without leaving WeCom. The Smart Robot can only be configured in **Custom App Integration** mode.
diff --git a/en/rum/sdk/android/data-collection.mdx b/en/rum/sdk/android/data-collection.mdx
index 9a3b259e0..bc78b5081 100644
--- a/en/rum/sdk/android/data-collection.mdx
+++ b/en/rum/sdk/android/data-collection.mdx
@@ -174,6 +174,7 @@ Flashcat RUM can infer geographic location information from user's IP address:
| `geo.country` | string | Country name |
| `geo.country_iso` | string | Country ISO code |
| `geo.city` | string | City name |
+| `geo.province` | string | Province name, populated only for China IPs. Derived by the backend from the reporting IP (not sent by the SDK), using English province names (for example, `Guangdong`, `Inner Mongolia`); it can be populated even when the city is unknown |
<Note>
Geo-location information is inferred by Flashcat backend based on client IP address. Precise GPS location is not collected on the Android client, and location permissions are not required.
diff --git a/en/rum/sdk/ios/data-collection.mdx b/en/rum/sdk/ios/data-collection.mdx
index b3c9dd088..02e43e866 100644
--- a/en/rum/sdk/ios/data-collection.mdx
+++ b/en/rum/sdk/ios/data-collection.mdx
@@ -107,6 +107,7 @@ The following attributes relate to IP address geo-location:
| `geo.continent_code` | String | Continent ISO code (for example, `EU`, `AS`) |
| `geo.continent` | String | Continent name |
| `geo.city` | String | City name |
+| `geo.province` | String | Province name, populated only for China IPs. Derived by the backend from the reporting IP (not sent by the SDK), using English province names (for example, `Guangdong`, `Inner Mongolia`); it can be populated even when the city is unknown |
<Note>
Geo-location information is inferred by Flashcat backend based on client IP address. Precise GPS location is not collected on the client.
diff --git a/en/rum/sdk/web/data-collection.mdx b/en/rum/sdk/web/data-collection.mdx
index 674dd13cb..6d4196406 100644
--- a/en/rum/sdk/web/data-collection.mdx
+++ b/en/rum/sdk/web/data-collection.mdx
@@ -71,6 +71,7 @@ Web RUM SDK automatically captures the following default attributes, applicable
| `geo.continent_code` | String | Continent ISO code (for example, `EU`, `AS`, `NA`) |
| `geo.continent` | String | Continent name |
| `geo.city` | String | City name |
+| `geo.province` | String | Province name, populated only for China IPs. Derived by the backend from the reporting IP (not sent by the SDK), using English province names (for example, `Guangdong`, `Inner Mongolia`); it can be populated even when the city is unknown |
<Note>
Geo-location information is inferred by FlashCat backend based on client IP address. Precise GPS location is not collected on the client.
diff --git a/zh/ai-sre.mdx b/zh/ai-sre.mdx
index 471c27c94..cc9792a04 100644
--- a/zh/ai-sre.mdx
+++ b/zh/ai-sre.mdx
@@ -42,7 +42,7 @@ Flashduty AI SRE 是一个对话式的自治 SRE Agent 平台。您用自然语
在 Slack / 飞书 / 钉钉 / 企业微信里 @ AI SRE 即可发起或续接排查，团队全程可见
</Card>
<Card title="作战室自动诊断" icon="people-group">
- 为故障开启 IM 作战室时，AI SRE 自动跑一轮初步诊断并把结论回贴到作战室
+ 为故障开启 IM 作战室、且一条启用中的**作战室创建触发**自动化规则命中该故障时，AI SRE 自动跑一轮初步诊断并把结论回贴到作战室
</Card>
<Card title="运营复盘洞察" icon="gauge-high">
用 /insight 复盘最近 30 天会话，量化运维摩擦并输出可复制的改进建议
diff --git a/zh/ai-sre/automations.mdx b/zh/ai-sre/automations.mdx
index 1d0b27594..34ca9a7c1 100644
--- a/zh/ai-sre/automations.mdx
+++ b/zh/ai-sre/automations.mdx
@@ -1,7 +1,7 @@
---
title: 自动化
-description: 让 AI SRE 按 cron 周期、HTTP API 或 On-call 故障事件自动运行一个隐藏会话，用一段任务提示词产出巡检、洞察或复盘结果；本文介绍自动化规则的新建、配置字段、触发方式、运行历史与权限。
-keywords: ["AI SRE", "自动化", "Automation", "巡检", "定时任务", "cron", "HTTP 触发", "On-call 故障触发", "手动执行", "运行历史", "隐藏会话"]
+description: 让 AI SRE 按 cron 周期、HTTP API、On-call 故障事件或作战室创建自动运行一次任务，用一段任务提示词产出巡检、洞察或复盘结果；本文介绍自动化规则的新建、配置字段、触发方式、运行历史与权限。
+keywords: ["AI SRE", "自动化", "Automation", "巡检", "定时任务", "cron", "HTTP 触发", "On-call 故障触发", "作战室创建触发", "手动执行", "运行历史", "隐藏会话"]
sidebarTitle: 自动化
---
@@ -16,13 +16,14 @@ sidebarTitle: 自动化
- **按周期执行**：用 4 段或 5 段 cron 设定运行节奏（例如每周一上午、每天 09:15），到点自动跑。
- **经 API 调用**：生成一个带 Bearer Token 的触发地址，您在外部系统里用 `POST` 按需触发，把本次运行的上下文随请求体一起带进来。
- **On-call 故障触发**：选择要监听的 On-call 协作空间与严重程度，当匹配故障产生时自动拉起一次诊断运行。
+- **作战室创建触发**：选择要监听的协作空间与严重程度，当匹配的故障创建作战室时自动拉起一次诊断运行；这次运行的会话建在作战室的 IM 群里，不在控制台。
什么时候用它：把重复的例行巡检（如每日健康巡检）、定期产出的洞察 / 复盘报告交给 AI SRE 自动跑；或者把 AI SRE 接进您已有的流水线、变更系统或 On-call 故障流，在事件发生时拉起一次诊断。
入口：左侧导航 **AI SRE → 自动化**，对应路由 `/ai-sre/automations`。
<Note>
-自动化跑出的每一次运行，本质上仍是一个 AI SRE 会话——只是它被标记为隐藏，不混进您的日常会话列表。您随时可以从运行历史点进去，看到这次运行完整的对话、工具调用与产物。
+自动化跑出的每一次运行，本质上仍是一个 AI SRE 会话——只是它被标记为隐藏，不混进您的日常会话列表。您随时可以从运行历史点进去，看到这次运行完整的对话、工具调用与产物（跑在 IM 群里的 **作战室创建触发** 运行除外，见下文“作战室创建触发（War room created）”）。
</Note>
## 新建自动化
@@ -58,7 +59,7 @@ sidebarTitle: 自动化
## 触发方式
-一条规则必须 **至少配置一种触发方式**。当前控制台表单在“触发方式”区提供 **按周期执行**、**经 API 调用** 与 **On-call 故障触发** 三种入口，三者可同时启用。
+一条规则必须 **至少配置一种触发方式**。当前控制台表单在“触发方式”区提供 **按周期执行**、**经 API 调用**、**On-call 故障触发** 与 **作战室创建触发** 四种入口，四种可同时启用。
### 按周期执行（cron）
@@ -192,9 +193,43 @@ curl -X POST 'https://<触发地址>' \
相似度比较依赖账户的 AIOps 能力与专业版及以上订阅：平台关闭 AIOps、或账户版本不满足时，比较不会执行，每个故障各自拉起一次运行。
</Note>
+### 作战室创建触发（War room created）
+
+当您希望故障一建作战室就让 AI SRE 进场时，添加 **War room created** 触发方式。触发器会向 On-call 侧注册一个订阅，只有匹配指定协作空间和严重程度的作战室创建事件才会启动运行。
+
+<Steps>
+ <Step title="添加触发方式">
+ 在“触发方式”中点击 **War room created** 卡片，表单会展开协作空间与严重程度条件；严重程度默认选中 `Critical`。
+ </Step>
+ <Step title="选择协作空间">
+ 在 **协作空间** 下拉框中选择要监听的协作空间。个人范围规则可选择账户下可见的协作空间；团队范围规则会按所选团队收窄可选协作空间。启用该触发器时至少需要一个协作空间。
+ </Step>
+ <Step title="选择严重程度">
+ 在 **严重程度** 中选择 `Critical`、`Warning`、`Info` 中的一个或多个值。启用该触发器时至少需要一个值。
+ </Step>
+</Steps>
+
+<Note>
+这次运行的会话建在作战室的 **IM 群聊** 里，不在控制台——触发卡片上标着“会话基于 IM 群聊创建。”，并附一条平台提示：由于平台限制，可能对企业微信和钉钉集成不适用。
+</Note>
+
+如果通过 API 创建或更新规则，对应字段如下：
+
+| 字段 | 类型 | 说明 |
+|---|---|---|
+| `war_room_trigger_enabled` | boolean | 是否启用作战室创建触发器。 |
+| `war_room_channel_ids` | int64[] | 监听的协作空间 ID 列表；创建或启用该触发器时至少需要一个有效 ID。 |
+| `war_room_severities` | string[] | 监听的严重程度，支持 `Critical`、`Warning`、`Info`；创建或启用该触发器时至少需要一个值。 |
+
+匹配的作战室创建后，系统会以 `war_room_created` 作为 `trigger_kind` 创建运行，并把 `incident_id`、`channel_id`、`severity` 等上下文带进会话。这次运行不在控制台里新建会话，而是直接在作战室群里跑一轮分析，结论也发回这个群。同一条触发器下、同一个故障只启动一次运行，重复的事件不会另起会话。
+
+**执行环境**：这条触发方式不使用规则上的 **执行环境**——作战室里的分析用群里已经选好的执行环境。规则的唯一触发方式是作战室创建时，表单不显示环境选择器，只提示“作战室里的分析用这个群已经选好的执行环境，规则上不再选。”；同时启用了周期 / API / 故障触发时，环境选择器照常出现，并提示“周期、API 和故障触发使用这里的执行环境。作战室触发使用群里的执行环境，不会改掉群里已经选好的。”。
+
+预设模板 **作战室初步分析**（模板键 `war_room_initial_analysis`，分类 **故障响应**）预置了这条触发方式与 `Critical` 严重程度；协作空间不由模板预置，需要您自己选。
+
## 运行历史
-每条规则都保留它的运行历史。点击规则行即可打开规则详情页（`/ai-sre/automations/:ruleId`）：左栏是 **配置信息**，右栏是 **执行历史**；右栏顶部的 **手动执行** 按钮可直接触发一次运行。
+每条规则都保留它的运行历史。点击规则行即可打开规则详情页（`/ai-sre/automations/:ruleId`）：左栏是 **配置信息**，右栏是 **执行历史**；右栏顶部的 **手动执行** 按钮可直接触发一次运行。规则的唯一触发方式是 **作战室创建触发** 时不会出现这个按钮——这类规则的运行跑在 IM 群里，没有控制台运行。
运行历史以表格呈现，列为：
@@ -203,7 +238,8 @@ curl -X POST 'https://<触发地址>' \
| 名称 | 本次运行对应的隐藏会话标题（`session_name`），解析不到时显示会话 ID（`session_id`）。被并入其它分析的运行没有自己的会话，改显示对应的故障（`#<num> <title>`），并在下一行标明并入了哪次分析 |
| 执行时间 | 本次运行的开始时间 |
| 耗时 | 本次运行的持续时长 |
-| 触发方式 | 本次运行的触发类型标签，如 `定时`（schedule）、`HTTP POST`、`On-call incident` 或 `手动执行` |
+| 触发方式 | 本次运行的触发类型标签，如 `定时`（schedule）、`HTTP POST`、`On-call incident`、`手动执行` 或 `作战室创建触发`（war_room_created） |
+| 执行位置 | 本次运行跑在哪里：`IM`（会话在 IM 群里，例如作战室创建触发的运行）或 `Web 控制台`（控制台里的隐藏会话）。对应 API 字段 `execution_place`，取值为 `im` / `web_console`；记录里没有这个字段时，作战室创建触发的运行按 `IM` 显示，其余按 `Web 控制台` 显示 |
| 状态 | 本次运行的状态（见下表） |
运行状态的取值：
@@ -223,11 +259,11 @@ curl -X POST 'https://<触发地址>' \
- **时间范围**：默认显示 **最近 30 天**，可调整范围，最大跨度 **180 天**。
- **状态**：按上表中的运行状态过滤，或选 **全部状态**。
-- **触发类型**：`全部触发类型` / `手动执行` / `定时` / `HTTP POST` / `On-call incident` 五选一。
+- **触发类型**：`全部触发类型` / `手动执行` / `定时` / `HTTP POST` / `On-call incident` / `作战室创建触发` 六选一。
-API 返回的运行记录还包含 `trigger_kind`，可能取值为 `schedule`、`manual`、`http_post`、`oncall_incident` 或 `debug`。其中 `manual` 表示通过立即执行接口启动，`oncall_incident` 表示由匹配的 On-call 故障事件启动。被并入其它分析的运行不返回自己的 `session_id`，而是返回它并入的那次分析的会话 ID `joined_session_id` 与会话名 `joined_session_name`；这两个字段为空，表示这次运行有自己的隐藏会话。
+API 返回的运行记录还包含 `trigger_kind`，可能取值为 `schedule`、`manual`、`http_post`、`oncall_incident`、`war_room_created` 或 `debug`。其中 `manual` 表示通过立即执行接口启动，`oncall_incident` 表示由匹配的 On-call 故障事件启动，`war_room_created` 表示由作战室创建触发启动（会话在 IM 群里）。被并入其它分析的运行不返回自己的 `session_id`，而是返回它并入的那次分析的会话 ID `joined_session_id` 与会话名 `joined_session_name`；这两个字段为空，表示这次运行有自己的隐藏会话。
-点击一行，会跳转到这次运行对应的隐藏会话对话页，让您查看该次运行完整的消息、工具调用与产物。被并入其它分析的运行没有自己的会话，点击它会打开接管这个故障的那次分析。
+点击一行，会跳转到这次运行对应的隐藏会话对话页，让您查看该次运行完整的消息、工具调用与产物。跑在 IM 群里的运行（`execution_place=im`，或由 `war_room_created` 触发）不跳转，而是弹出一句 **本分析位于 IM，请进入 IM 查看。**——这次分析的对话在 IM 群里读。被并入其它分析的运行没有自己的会话，点击它会打开接管这个故障的那次分析。
### 未成功运行的原因行
@@ -257,7 +293,7 @@ API 返回的运行记录还包含 `trigger_kind`，可能取值为 `schedule`
| 操作 | 说明 |
|---|---|
| 启用 / 停用 | 行内开关。停用后规则保留，但不再触发；停用不会删除已有运行历史。 |
-| 立即执行 | 在规则行手动启动一次真实运行。该操作会先做运行前检查，然后为本次运行创建一个隐藏会话；同一规则手动执行最多每分钟一次。 |
+| 立即执行 | 在规则行手动启动一次真实运行。该操作会先做运行前检查，然后为本次运行创建一个隐藏会话；同一规则手动执行最多每分钟一次。当规则的唯一触发方式是 **作战室创建触发** 时，列表和详情页都不提供这个操作——这类规则不会产生控制台运行，调用立即执行接口会直接报错。 |
点击规则行任意位置会打开该规则的详情页，在详情页里可以编辑配置、删除规则，也能看到运行历史（见上文“运行历史”一节）。
@@ -277,6 +313,7 @@ API 返回的运行记录还包含 `trigger_kind`，可能取值为 `schedule`
| 编辑 / 管理（个人规则） | 仅创建者本人可管理和查看。账户 Owner 与管理员也无法查看或管理他人的个人规则。 |
| HTTP POST 触发 | 通过触发地址发起一次真实运行时，鉴权只看该 trigger 的 Bearer Token；持有 Token 的外部系统可以触发，运行会按规则的个人或团队作用域创建隐藏会话。 |
| On-call 故障触发 | 由已注册的故障订阅触发，不使用 HTTP POST Bearer Token；运行仍按规则的个人或团队作用域创建隐藏会话。 |
+| 作战室创建触发 | 由已注册的作战室创建订阅触发，不使用 HTTP POST Bearer Token；会话建在作战室的 IM 群里而不是控制台，运行仍按规则的个人或团队作用域归属。 |
<Note>
账户 Owner / 管理员能在列表中看到其他成员的个人规则（见上表“可见 / 列表”），但点击进入详情页会被拒绝——“编辑 / 管理”权限对个人规则同样不因 Owner / 管理员身份而豁免，与团队规则一致。
diff --git a/zh/ai-sre/im.mdx b/zh/ai-sre/im.mdx
index 2c34d2879..3e1f492c6 100644
--- a/zh/ai-sre/im.mdx
+++ b/zh/ai-sre/im.mdx
@@ -1,6 +1,6 @@
---
title: IM 平台
-description: AI SRE 是 IM 原生的——在 Slack、飞书、钉钉、企业微信的群聊或私聊里 @ 它即可发起或续接排查，它在线程内作答；为故障开启作战室时可按集成设置自动执行一轮初步诊断并发回结果。
+description: AI SRE 是 IM 原生的——在 Slack、飞书、钉钉、企业微信的群聊或私聊里 @ 它即可发起或续接排查，它在线程内作答；为故障开启作战室时，可由一条「作战室创建触发」的自动化规则自动执行一轮初步诊断并发回结果。
keywords: ["AI SRE", "IM", "Slack", "飞书", "钉钉", "企业微信", "作战室", "war room", "@提及", "故障协作"]
sidebarTitle: IM 平台
---
@@ -18,7 +18,7 @@ AI SRE 的 IM 集成有两种触发方式：
在群聊或私聊里 **@ AI SRE** 并描述问题，即可发起或续接一次排查。它在**线程内**回答，对话上下文与这条 IM 会话绑定。
</Card>
<Card title="作战室自动诊断" icon="people-group">
- 为故障开启 IM 作战室时，若该集成保留默认开启的 **自动发起 AI 故障分析**，AI SRE 会执行一轮初步诊断，并把结论作为一条分析消息发回作战室——无需任何人手动召唤。
+ 为故障开启 IM 作战室时，若账户里有一条启用中的 **作战室创建触发** 自动化规则、且这条故障的协作空间与严重程度命中该规则，AI SRE 会执行一轮初步诊断，并把结论作为一条分析消息发回作战室——无需任何人手动召唤。
</Card>
</CardGroup>
@@ -26,12 +26,12 @@ AI SRE 的 IM 集成有两种触发方式：
AI SRE 的 IM 交互覆盖四个主流平台，每个平台都支持入站的 @ 提及（webhook）、历史消息读取与出站回复：
-| 平台 | 群聊 @ 提及 | 私聊（DM） | 处理中回执 | 作战室自动诊断 |
-| --- | --- | --- | --- | --- |
-| Slack | ✅ | ✅ | ✅ 表情（另有原生“正在处理”状态） | ✅ |
-| 飞书 / Lark | ✅ | ✅ | ✅ 表情 | ✅ |
-| 钉钉 / DingTalk | ✅ | ✅ | ✅ 内置表情 | ✅ |
-| 企业微信 / WeCom | ✅ | ✅ | ✅ 占位消息 | ✅ |
+| 平台 | 群聊 @ 提及 | 私聊（DM） | 处理中回执 |
+| --- | --- | --- | --- |
+| Slack | ✅ | ✅ | ✅ 表情（另有原生“正在处理”状态） |
+| 飞书 / Lark | ✅ | ✅ | ✅ 表情 |
+| 钉钉 / DingTalk | ✅ | ✅ | ✅ 内置表情 |
+| 企业微信 / WeCom | ✅ | ✅ | ✅ 占位消息 |
“处理中回执”是机器人收到您的消息后给出的即时信号，各平台的具体形式见[处理中回执](#处理中回执)。
@@ -41,9 +41,8 @@ IM 交互依赖您已在 Flashduty 中接入对应平台的机器人（用于告
## IM 集成中的 AI SRE 设置
-在 **On-call → 集成中心 → 集成列表 → 即时消息** 打开对应 IM 集成详情，在 **增强功能** 中分别配置该集成的 AI SRE 行为。以下开关默认均为开启：
+在 **On-call → 集成中心 → 集成列表 → 即时消息** 打开对应 IM 集成详情，在 **增强功能** 中配置该集成的 AI SRE 行为。以下两个开关默认均为开启：
-- **自动发起 AI 故障分析**：开启作战室后可配置；集成成功创建作战室时，自动发起一次 AI SRE 初步诊断并把结果发回作战室。
- **允许在 IM 中使用 AI SRE**：无需开启作战室即可配置，同时控制 **群聊 @ 提及** 与 **机器人私聊** 两个入口；Slack 在此之外还控制 `/fd` 命令。关闭后，群聊 @ 提及、机器人私聊（Slack 另含 `/fd` 命令）都不会触发 AI SRE 回复。企业微信的第三方应用模式只支持机器人私聊，群聊 @ 提及需使用企业自建应用模式。
- **普通群聊中 AI SRE 使用话题回复**：仅飞书/Lark 与 Slack 提供。开启后，普通群聊中的每个话题对应一个独立 Session；作战室仍直接在群内回复。
@@ -104,20 +103,22 @@ AI SRE 在 IM 里的答复**只经 `reply` 工具投递**——模型输出的
## 作战室自动诊断
-当您为一个故障在 IM 中开启**作战室**（war room）且该集成保留 **自动发起 AI 故障分析** 开关时，AI SRE 会自动介入——无需任何人 @ 它：
+作战室建好后 AI SRE 是否自动进场，由账户里的 **作战室创建触发** 自动化规则决定，而不是 IM 集成上的某个开关：创建作战室本身只发布一个创建事件，不会直接拉起分析——**有命中的规则才跑，没有就不跑**。所以这条链路不需要任何人 @ 它，但前提是您已经配好这样一条规则：
<Steps>
<Step title="创建作战室">
在故障的协作流程中创建作战室（飞书 / 钉钉 / 企业微信 / Slack 群）。
</Step>
- <Step title="后台拉起诊断">
- 作战室建好后，平台会以**非阻塞后台任务**触发一轮初步诊断，让 AI SRE 带着该故障的上下文进入排查。
+ <Step title="匹配作战室创建触发的规则">
+ 平台会拿这次创建去匹配账户里已启用的 **作战室创建触发** 规则：故障所属**协作空间**要在规则选中的列表里，故障**严重程度**也要命中规则，两项都满足才会启动一轮运行。没有命中的规则时不产生任何分析。
</Step>
<Step title="发回结论">
- 诊断完成后，AI SRE 把分析结果作为一条消息发回作战室。人还没开始排查，第一手分析就已经摆在群里了。
+ 这次运行以该作战室的 IM 群为会话落点（不建控制台会话），AI SRE 带着这个故障的上下文排查，并把结论发回作战室。人还没开始排查，第一手分析就已经摆在群里了。
</Step>
</Steps>
+规则的触发卡片上要选什么、怎么建，见[自动化 · 作战室创建触发](/zh/ai-sre/automations#作战室创建触发war-room-created)。
+
<Note>
作战室自动诊断与故障上下文绑定：进入排查时，对应的 `incident_id` 会绑定到本次运行，AI SRE 可据此读取故障详情、时间线与近期变更。关于故障 / 作战室与 A2A 的联动细节，见 [Agent · 故障与作战室联动](/zh/ai-sre/agents#故障与作战室联动)。
</Note>
diff --git a/zh/ai-sre/overview.mdx b/zh/ai-sre/overview.mdx
index 0dcec2c4b..a8a5c104f 100644
--- a/zh/ai-sre/overview.mdx
+++ b/zh/ai-sre/overview.mdx
@@ -38,7 +38,7 @@ AI SRE 不止是控制台里的一个对话框——它围绕“故障从触发
无需切换工具——在 Slack、飞书、钉钉、企业微信的群聊或私聊里 **@ AI SRE** 即可发起或续接一次排查，它在**线程内**回答，团队成员全程可见。详见 [IM 集成](/zh/ai-sre/im)。
</Card>
<Card title="作战室自动诊断" icon="people-group">
- 为故障开启 IM 作战室时，AI SRE **自动执行一轮初步诊断**并把结论发回作战室——人还没开始排查，第一手分析就已经在群里了。
+ 为故障开启 IM 作战室、且账户里一条启用中的**作战室创建触发**[自动化规则](/zh/ai-sre/automations)命中该故障时，AI SRE **自动执行一轮初步诊断**并把结论发回作战室——人还没开始排查，第一手分析就已经在群里了。
</Card>
<Card title="运营复盘洞察" icon="gauge-high">
用 [`/insight`](/zh/ai-sre/insight) 复盘最近 30 天的会话，量化您把时间花在了哪里、哪些 runbook 缺失、哪些上下文被反复粘贴，输出可复制的改进建议。
@@ -96,7 +96,7 @@ AI SRE 围绕"对话排障 + 知识沉淀 + 自主执行"构建了一套完整
以会话为单位与 Agent 协作。会话按顺序处理您的每条消息，支持流式输出、随时取消、长对话自动压缩上下文，以及从故障一键拉起。
</Card>
<Card title="IM 平台" icon="comment-dots" href="/zh/ai-sre/im">
- 在 Slack / 飞书 / 钉钉 / 企业微信中 @ Agent 发起或续接排查，并在故障作战室里自动给出初步诊断。
+ 在 Slack / 飞书 / 钉钉 / 企业微信中 @ Agent 发起或续接排查，并在故障作战室里由[自动化规则](/zh/ai-sre/automations)自动给出初步诊断。
</Card>
<Card title="Skill" icon="wrench" href="/zh/ai-sre/skills">
可被 Agent 调用的 Skill 包，封装可复用的排障流程。范围可设为共享（即账户级）或团队，启用后在会话中按需加载。
diff --git a/zh/ai-sre/quickstart.mdx b/zh/ai-sre/quickstart.mdx
index 5dbb23071..286a8d29d 100644
--- a/zh/ai-sre/quickstart.mdx
+++ b/zh/ai-sre/quickstart.mdx
@@ -34,7 +34,7 @@ AI SRE 没有唯一入口，从您现在所在的场景开始就好：
### IM（@ 召唤 + 作战室自动诊断）
-故障发生的现场。在已接入机器人的群里（Slack、飞书、钉钉或企业微信）**@ AI SRE**，即可发起或续接排查，AI SRE 在线程内作答；为故障开启作战室时，AI SRE 会自动执行一轮初步诊断并把结论发回作战室。→ 详见[IM 平台](/zh/ai-sre/im)
+故障发生的现场。在已接入机器人的群里（Slack、飞书、钉钉或企业微信）**@ AI SRE**，即可发起或续接排查，AI SRE 在线程内作答；为故障开启作战室、且账户里一条带**作战室创建触发**的[自动化规则](/zh/ai-sre/automations)命中该故障时，AI SRE 会自动执行一轮初步诊断并把结论发回作战室。→ 详见[IM 平台](/zh/ai-sre/im)
## 第一次排障（约 5 分钟）
@@ -80,7 +80,7 @@ AI SRE 没有唯一入口，从您现在所在的场景开始就好：
手动排查顺了之后，把它变成默认动作：进入 **AI SRE → 自动化**，从内置模板 **故障自动分析** 创建规则，在“触发方式”里启用 **On-call incident** 卡片，选好要监听的协作空间和严重程度。之后每条匹配的新故障创建时，AI SRE 都会自动执行一轮排查，并把一条总结评论写回这条故障——结论在最前面，末尾附完整会话链接；评论沿故障现有的通知链路推送，响应人在 IM 里就能看到第一手分析。配置细节见[自动化 · On-call 故障触发](/zh/ai-sre/automations#on-call-故障触发)。
-它与作战室自动诊断是两条独立链路：这条对每一条匹配的新故障生效，结果写回故障评论；作战室自动诊断在您为故障开启 IM 作战室时运行，结果发回作战室群里（见 [IM 平台](/zh/ai-sre/im)）。
+它与作战室自动诊断是两条独立链路：这条对每一条匹配的新故障生效，结果写回故障评论；作战室自动诊断由一条带**作战室创建触发**的自动化规则驱动，在您为故障开启 IM 作战室且规则命中时运行，结果发回作战室群里（见 [IM 平台](/zh/ai-sre/im)）。
### 建一份团队知识
diff --git a/zh/changelog/changelog.mdx b/zh/changelog/changelog.mdx
index ecb8a2300..aa50f3ba3 100644
--- a/zh/changelog/changelog.mdx
+++ b/zh/changelog/changelog.mdx
@@ -4,6 +4,23 @@ description: "本页面记录 Flashduty 产品的重要更新和功能发布"
keywords: ["更新日志", "产品发布", "功能更新", "Flashduty", "版本记录"]
---
+<Update label="2026-10-13" description="🤖 AI SRE 自动化新增「作战室创建触发」、告警规则的关联查询与恢复查询支持 Go 模板">
+
+### AI SRE 自动化新增「作战室创建触发」
+
+自动化的触发方式在 **按周期执行**、**经 API 调用**、**On-call 故障触发** 之外新增第四种 **作战室创建触发**（`trigger_kind` 为 `war_room_created`）：选择要监听的协作空间与严重程度（默认选中 `Critical`），当所选协作空间里创建了符合严重程度条件的作战室时，自动跑一次诊断——这次运行的会话建在作战室的 IM 群聊里、不在控制台，结论也发回该群。预设模板 **作战室初步分析**（模板键 `war_room_initial_analysis`，分类 **故障响应**）已预置这条触发方式与 `Critical` 严重程度，协作空间不由模板预置、需要您自己选。
+
+与此配套，IM 集成配置页 **增强功能** 里不再有 **自动发起 AI 故障分析** 开关：作战室创建后的自动分析改由自动化规则驱动，想让 AI SRE 在作战室一建就进场，请在自动化里启用一条带 **作战室创建触发** 的规则。详见 [AI SRE 自动化](/zh/ai-sre/automations)。
+
+### 告警规则：关联查询与恢复查询支持 Go 模板
+
+**恢复查询** 与 **关联查询** 的表达式现在除 `${label_name}` 之外还接受 Go 模板写法 `{{ $labels.<标签名> }}`，按**告警实例**逐条渲染——每个实例用自己那份标签渲染一次，同一条规则对不同实例会得到不同的查询语句。两种写法 **二选一**：同一条表达式里同时出现 `${...}` 与 `{{...}}` 会在保存时被拒绝，不同表达式之间互相独立、可以各写一种。模板内只有当前告警实例的 `$labels`，可用函数限于 `len`、`index`、`regexQuoteMeta`、`replace`、比较与逻辑函数（`eq`、`ne`、`lt`、`le`、`gt`、`ge`、`and`、`or`、`not`）以及 `if`/`else`；`printf` 等格式化函数、Sprig 函数集、`range` 循环与 `define`/`block` 都会被拒绝。**主查询不支持** 模板，也不受这套规则影响。
+
+私有化部署需要留意版本：使用 Go 模板时，该规则匹配到的数据源所在集群内 **所有** 已注册的 monit-edge 都必须是 `v0.75.4` 或以上，否则保存会被拒绝；继续使用 `${label_name}` 不受这个版本限制。详见[告警规则 · Prometheus](/zh/monitors/alert-rules/prometheus)。
+
+</Update>
+
+
<Update label="2026-10-09" description="📊 仪表盘内置时间变量与显示时区、RUM 查看器聚合分析、MCP Server 与 Go SDK 支持 OAuth 授权">
### 仪表盘：内置时间变量与显示时区
diff --git a/zh/developer/cli.mdx b/zh/developer/cli.mdx
index 22e4b2e33..1999dcb5e 100644
--- a/zh/developer/cli.mdx
+++ b/zh/developer/cli.mdx
@@ -657,6 +657,8 @@ flashduty monit dashboard-runtime-queries-resolve <panel-id> [<id2>...] # 解
面板运行时与变量解析的时间窗口、变量选择都以 JSON 对象放在 `--data` 里（时间用 `from_ms` / `to_ms` 的毫秒时间戳）。`dashboard-panel-preview` 与 `dashboard-runtime-variables-preview` 需要一个 `context`：`kind: existing` 配 `dashboard_id` 指向已存仪表盘，`kind: new` 配 `folder_id` 指向尚未落库的分组。
+`dashboard-runtime-queries-resolve` 另有两个影响解析结果的参数：`--max-data-points`（整数，取值 2–5000；既作降采样目标，也决定解析出的表达式里内置时间变量渲染出的步长，省略或传 `null` 时取服务端默认值 100）与 `--preserve-builtin-variables`（布尔，默认关）：开启后**内置时间变量**在解析结果里原样保留，交由自带执行窗口的调用方自行渲染，用户变量仍会被解析。兄弟命令 `dashboard-panel-run` 与 `dashboard-panel-preview` 早已带 `--max-data-points`，同为 2–5000 的降采样目标。
+
#### `prometheus-api-v1-label-{label_name}-values` — 查询 Prometheus 标签值
`GET /monit/prometheus/api/v1/label/{label_name}/values`（operationId `monit-prometheus-read-label-values`）带路径参数，因此不参与代码生成，由手工实现命令提供。命令名沿用生成命令的路径派生写法（`monit` 组 + 路径剩余段连字符拼接），因此在 `flashduty monit --help` 下可见、但无法按直觉猜到，需要按本节的写法使用：
@@ -685,7 +687,7 @@ flashduty alert get <alert_id> # 查看单条告警详情；detail 是同
flashduty alert-event list [flags] # 列出告警事件（默认最近 1 小时）
```
-两个 `list` 命令常用过滤参数：`--severity`（`Critical,Warning,Info`）、`--channel`（逗号分隔协作空间 ID）、`--integration`（逗号分隔的集成 ID）、`--since`/`--until`、`--limit`（最大 100）、`--page`。`alert-event list` 另有 `--integration-type`，按逗号分隔的**插件键**过滤（如 `AliCloud,Prometheus`）——注意它取插件键而非集成 ID，按集成 ID 过滤请使用 `--integration`。
+两个 `list` 命令常用过滤参数：`--severity`（`Critical,Warning,Info`）、`--channel`（逗号分隔协作空间 ID）、`--integration`（逗号分隔的集成 ID）、`--since`/`--until`、`--limit`（最大 100）、`--page`。`--since` 与 `--until` 之间的窗口须小于 31 天（与 `incident list`、`change list` 相同）。`alert-event list` 另有 `--integration-type`，按逗号分隔的**插件键**过滤（如 `AliCloud,Prometheus`）——注意它取插件键而非集成 ID，按集成 ID 过滤请使用 `--integration`。
`alert list` 另有 `--alert-ids`（逗号分隔的告警 ID）、`--alert-keys`（逗号分隔的告警去重键）、`--asc`（按开始时间升序，默认最新在前）、`--by-updated-at`（把 `--since`/`--until` 应用到最近更新时间，而不是开始时间）；`alert-event list` 也支持 `--asc`（升序，默认最新在前），但没有 `--by-updated-at`。
@@ -723,7 +725,7 @@ flashduty automation fire <trigger_id> # 经 HTTP POST 触发器触
`update` 可改字段：`--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`、`--environment-kind`/`--environment-id`。个人 / 团队作用域创建后不可变更，`update` 不提供改作用域的参数。
-`runs` 支持 `--status`（`queued`/`running`/`retrying`/`succeeded`/`partial`/`failed`/`skipped`/`abandoned`）、`--trigger-kind`（`schedule`/`debug`/`http_post`）、`--since`/`--until`、`--page`、`--limit`。`fire` 用触发器的 Token 鉴权（`--token`，或环境变量 `FLASHDUTY_AUTOMATION_TRIGGER_TOKEN`），`--text` 传本次运行的上下文，`--data` 传完整 JSON 请求体（内联 JSON 或 `-` 读 stdin）。
+`runs` 支持 `--status`（`queued`/`running`/`retrying`/`succeeded`/`partial`/`failed`/`skipped`/`abandoned`）、`--trigger-kind`（服务端取值 `schedule`/`debug`/`manual`/`http_post`/`oncall_incident`/`war_room_created`，其中 `war_room_created` 表示由作战室创建触发的运行）、`--since`/`--until`、`--page`、`--limit`。`fire` 用触发器的 Token 鉴权（`--token`，或环境变量 `FLASHDUTY_AUTOMATION_TRIGGER_TOKEN`），`--text` 传本次运行的上下文，`--data` 传完整 JSON 请求体（内联 JSON 或 `-` 读 stdin）。
<Warning>
**时区语义**：`--at` 与 `--cron-expr` 均按**规则时区**的本地挂钟时间理解。`create` 省略 `--timezone` 时由服务端决定规则时区——依次取调用者的成员时区、账户时区，最后回退 `Asia/Shanghai`；需要固定其它时区时传入 IANA 名称（如 `--timezone Asia/Shanghai`），服务端无法加载的时区会被拒绝。`update` 省略 `--timezone` 时保留已存储的时区（包括历史遗留的空字符串），显式传空值 `--timezone ""` 会按 UTC 发送并存储，而不是账户默认时区。请直接传用户的本地时间，**不要**预先换算成 UTC。`update` 会立即重算下次触发时间，请以响应中的 `schedule_next_fire_at_ms` 为准。
@@ -773,6 +775,8 @@ flashduty safari --help # 查看 AI SRE 相关的生成命令
flashduty alert --help # 查看告警相关的生成命令
```
+`--data` 里的字段若在当前 CLI 版本的 SDK 中没有对应字段，这些字段**不会**被发出去：绑定请求体后 CLI 会在 stderr 打印一行 `warning: --data fields not sent, unknown to this CLI version: <字段路径>`（路径以点号分隔、数组元素以 `[]` 结尾，如 `labels.k.note`、`targets[].purpose`，多个字段用逗号分隔）。调用本身照常成功，stdout 不受影响——出现这行警告说明所传字段比本机 CLI 版本更新，依赖这些字段生效的脚本应先升级 CLI。
+
生成命令的时间窗口参数（`--start-time` / `--end-time`）与精选命令一样支持人性化的时间格式：相对时长（`7d`、`24h`，表示从当前往前推）、`+7d`（从当前往后推，即未来时间）、`now`、日期或日期时间（如 `2026-05-01`、`2026-05-01 10:00:00`）、Unix 秒级时间戳。此外，`--since` 和 `--until` 分别是 `--start-time` 和 `--end-time` 的别名，可互换使用；若两种写法同时传入且取值不同，CLI 会报冲突错误。
#### knowledge — AI SRE 知识
diff --git a/zh/developer/go-sdk.mdx b/zh/developer/go-sdk.mdx
index 3e23b0856..2a3d485b6 100644
--- a/zh/developer/go-sdk.mdx
+++ b/zh/developer/go-sdk.mdx
@@ -84,7 +84,7 @@ func main() {
| 返回值 | 类型 | 说明 |
|--------|------|------|
-| 数据 | `*T` | 接口对应的类型化响应体（如 `*ListIncidentsResponse`）；调用失败时为 `nil` |
+| 数据 | `*T` | 接口对应的类型化响应体（如 `*IncidentListResponse`）；调用失败时为 `nil` |
| `*Response` | `*flashduty.Response` | 包裹 `*http.Response`，并附带 `RequestID`、分页等信封元信息 |
| `error` | `error` | 失败时为 `*ErrorResponse`,429 时为 `*RateLimitError` |
@@ -138,7 +138,7 @@ client, err := flashduty.NewClientWithAccessToken(accessToken,
## 服务与方法
-接口按服务分组挂在客户端上：调用约定统一为 `client.<Service>.<Method>(ctx, req)`，返回 `(*T, *Response, error)`。例如 `client.Incidents.List(ctx, req)`、`client.Sessions.Info(ctx, req)`。
+接口按服务分组挂在客户端上：调用约定统一为 `client.<Service>.<Method>(ctx, req)`，返回 `(*T, *Response, error)`。例如 `client.Incidents.List(ctx, req)`、`client.Sessions.ReadInfo(ctx, req)`。
| 服务字段 | 说明 |
|----------|------|
@@ -155,8 +155,10 @@ client, err := flashduty.NewClientWithAccessToken(accessToken,
| `client.Account` | 账户 |
| `client.AuditLogs` | 审计日志 |
| `client.AlertRules` | 告警规则 |
+| `client.RuleFolders` | 规则分组；`List` 列出调用方可读的全部监控规则分组（`POST /monit/folder/list`） |
| `client.AlertEnrichment` | 告警字段加工 |
| `client.DataSources` | 数据源 |
+| `client.Dashboards` | 仪表盘；面板试跑与执行、面板查询解析（`QueryReadResolve`）、变量解析，以及仪表盘的读写、移动/恢复与修订历史 |
| `client.Integrations` | 集成 |
| `client.ImIntegrations` | IM 集成 |
| `client.NotificationTemplates` | 通知模板 |
diff --git a/zh/monitors/alert-rules/clickhouse.mdx b/zh/monitors/alert-rules/clickhouse.mdx
index d9254add0..8ae1f8540 100644
--- a/zh/monitors/alert-rules/clickhouse.mdx
+++ b/zh/monitors/alert-rules/clickhouse.mdx
@@ -48,7 +48,7 @@ Monitors 按标签字段区分告警对象，并使用值字段进行阈值判
|------|------|
| **自动恢复** | 当数值不再满足任何告警阈值时，自动生成恢复事件 |
| **特定恢复条件** | 配置恢复表达式（如 `$A.error_cnt < 5`） |
-| **恢复查询** | 独立 SQL 用于恢复判定，支持 `${label_name}` 变量 |
+| **恢复查询** | 独立 SQL 用于恢复判定，支持 `${label_name}` 变量；亦支持 Go 模板 `{{ $labels.<标签名> }}`（需 monit-edge `v0.75.4` 及以上） |
| **手工关闭** | 告警保持活动，直到用户手工关闭 |
## 数据存在模式
diff --git a/zh/monitors/alert-rules/elasticsearch.mdx b/zh/monitors/alert-rules/elasticsearch.mdx
index 4265d3fe0..78264df9d 100644
--- a/zh/monitors/alert-rules/elasticsearch.mdx
+++ b/zh/monitors/alert-rules/elasticsearch.mdx
@@ -58,7 +58,7 @@ Monitors 通过 ElasticSearch SQL 功能监控日志和指标数据，支持聚
|------|------|
| **自动恢复** | 当数值不再满足任何告警阈值时，自动生成恢复事件 |
| **特定恢复条件** | 配置恢复表达式（如 `$A.error_cnt < 5`），防止告警抖动 |
-| **恢复查询** | 编写独立 SQL 用于恢复判定，支持 `${label_name}` 变量 |
+| **恢复查询** | 编写独立 SQL 用于恢复判定，支持 `${label_name}` 变量；亦支持 Go 模板 `{{ $labels.<标签名> }}`（需 monit-edge `v0.75.4` 及以上） |
| **手工关闭** | 告警保持活动，直到用户手工关闭 |
<Accordion title="恢复查询示例">
diff --git a/zh/monitors/alert-rules/mysql.mdx b/zh/monitors/alert-rules/mysql.mdx
index f49e72f39..af45ef0ef 100644
--- a/zh/monitors/alert-rules/mysql.mdx
+++ b/zh/monitors/alert-rules/mysql.mdx
@@ -14,6 +14,8 @@ Monitors 支持使用标准 SQL 语法对 MySQL 进行查询，并根据查询
| **字段处理** | 所有字段名自动转换为小写，配置时请使用小写字母 |
| **时间处理** | 建议使用 `now()`、`unix_timestamp()` 等函数进行时间过滤 |
+MySQL 告警 SQL 在保存时必须完全确定：校验器会拒绝语句里的任何运行时变量（`${label_name}` 占位符与 `{{ $labels.<标签名> }}` Go 模板都不接受，关联查询和恢复查询同样如此），所以这类规则无法按告警实例渲染。
+
## 阈值判定模式
此模式适用于需要对聚合后的数值进行阈值比对的场景。
@@ -48,7 +50,7 @@ Monitors 按标签字段区分告警对象，并使用值字段进行阈值判
|------|------|
| **自动恢复** | 当数值不再满足任何告警阈值时，自动生成恢复事件 |
| **特定恢复条件** | 配置恢复表达式（如 `$A.error_cnt < 5`） |
-| **恢复查询** | 独立 SQL 用于恢复判定，支持 `${label_name}` 变量 |
+| **恢复查询** | 独立 SQL 用于恢复判定；SQL 必须完全确定，不能使用运行时变量 |
| **手工关闭** | 告警保持活动，直到用户手工关闭 |
## 数据存在模式
diff --git a/zh/monitors/alert-rules/oracle.mdx b/zh/monitors/alert-rules/oracle.mdx
index 4ba3ea373..c63aeffe9 100644
--- a/zh/monitors/alert-rules/oracle.mdx
+++ b/zh/monitors/alert-rules/oracle.mdx
@@ -48,7 +48,7 @@ Monitors 按标签字段区分告警对象，并使用值字段进行阈值判
|------|------|
| **自动恢复** | 当数值不再满足任何告警阈值时，自动生成恢复事件 |
| **特定恢复条件** | 配置恢复表达式（如 `$A.error_cnt < 5`） |
-| **恢复查询** | 独立 SQL 用于恢复判定，支持 `${label_name}` 变量 |
+| **恢复查询** | 独立 SQL 用于恢复判定，支持 `${label_name}` 变量；亦支持 Go 模板 `{{ $labels.<标签名> }}`（需 monit-edge `v0.75.4` 及以上） |
| **手工关闭** | 告警保持活动，直到用户手工关闭 |
## 数据存在模式
diff --git a/zh/monitors/alert-rules/postgres.mdx b/zh/monitors/alert-rules/postgres.mdx
index 067d5af7f..bb156f9c1 100644
--- a/zh/monitors/alert-rules/postgres.mdx
+++ b/zh/monitors/alert-rules/postgres.mdx
@@ -48,7 +48,7 @@ Monitors 按标签字段区分告警对象，并使用值字段进行阈值判
|------|------|
| **自动恢复** | 当数值不再满足任何告警阈值时，自动生成恢复事件 |
| **特定恢复条件** | 配置恢复表达式（如 `$A.error_cnt < 5`） |
-| **恢复查询** | 独立 SQL 用于恢复判定，支持 `${label_name}` 变量 |
+| **恢复查询** | 独立 SQL 用于恢复判定，支持 `${label_name}` 变量；亦支持 Go 模板 `{{ $labels.<标签名> }}`（需 monit-edge `v0.75.4` 及以上） |
| **手工关闭** | 告警保持活动，直到用户手工关闭 |
## 数据存在模式
diff --git a/zh/monitors/alert-rules/prometheus.mdx b/zh/monitors/alert-rules/prometheus.mdx
index f29304f3d..055112080 100644
--- a/zh/monitors/alert-rules/prometheus.mdx
+++ b/zh/monitors/alert-rules/prometheus.mdx
@@ -194,10 +194,45 @@ up{instance="${instance}", job="${job}"} == 1
告警引擎执行时，会将 `${instance}` 替换为 `host-1`，`${job}` 替换为 `node`，也就是告警事件标签中的具体值。
+#### Go 模板变量
+
+除 `${label_name}` 外，**恢复查询** 与 **关联查询** 的表达式还接受 Go 模板语法 `{{ $labels.<标签名> }}`。同一条表达式只能选用其中一种写法：表达式内同时出现 `${...}` 与 `{{...}` 时保存会被拒绝，报 `query expression mixes ${label} placeholders with Go template; use {{ $labels.name }} only`；不同表达式之间互相独立，可以各写一种。
+
+下面三类字段支持模板，**主查询不支持**——告警引擎不会对主查询做变量渲染，写在主查询里的 `{{ ... }}` 会被当作查询文本本身（在 PromQL 中会因语法非法而在保存时被拒绝）：
+
+- **关联查询**：规则中配置的所有关联查询语句。
+- **阈值恢复查询**：阈值判定模式下，恢复方式为"查询语句"时的恢复查询。
+- **数据存在/数据缺失恢复查询**：对应模式下，恢复方式为"查询语句"时的恢复查询。
+
+模板的上下文只有 `$labels`（当前告警实例的标签）：恢复查询与关联查询在告警事件组装之前执行，因此 `$values`、`$relates` 等变量在这里不可用。可用的函数只有 `len`、`index`、`regexQuoteMeta`、`replace`、`eq`、`ne`、`lt`、`le`、`gt`、`ge`、`and`、`or`、`not`，并支持 `if`/`else` 控制结构；`printf` 等格式化函数、Sprig 函数集、`range` 循环、`define`/`block`，以及 `.`/`.Field` 写法都会被拒绝（`.` 写法报 `use $labels to access instance labels`）。
+
+标签名本身含点号时（如 `service.name`）不能写成 `$labels.service.name`，需改用 `index $labels "service.name"`。
+
+假设告警实例带有 `host="host-1"`，恢复查询可以这样写：
+
+```
+up{host=~"{{ regexQuoteMeta $labels.host }}"} == 1
+```
+
+渲染后得到 `up{host=~"host-1"} == 1`。注意模板产出的值要由表达式自己加引号：上例里的 `"` 属于 PromQL 字符串，`{{ ... }}` 只负责产出值本身。
+
+<Warning>
+Go 模板需要 monit-edge `v0.75.4` 或以上版本。保存时校验会检查该规则匹配到的数据源所在集群内**所有**已注册的 monit-edge：只要有实例低于 `v0.75.4`，保存即被拒绝，错误提示以 `Go template relate or recovery queries require` 开头并指明所需版本为 `v0.75.4`。`${label_name}` 写法不受该版本限制。
+</Warning>
+
+#### 渲染时机与失败处理
+
+模板由 monit-edge 按**告警实例**逐条渲染：每个实例用自己那份标签渲染一次，同一条规则对不同实例会得到不同的查询语句。
+
+**表达式自己负责引号与转义。** 模板输出会原样插入，不做转义——`{{ $labels.host }}` 只产出标签值本身，引号要由表达式自己写（如上例的 `host=~"{{ ... }}"`）；标签值可能含引号等特殊字符时，请自行用 `regexQuoteMeta` 或 `replace` 处理。这与 `${label_name}` 不同：恢复查询里的 `${label_name}` 由引擎转义后放进查询的引号字面量中，而关联查询里的 `${label_name}` 是原样替换，且未匹配到的占位符会保留原样。
+
+**渲染失败**：关联查询渲染失败时（例如引用了告警事件里不存在的标签、模板语法非法），该条关联查询会被跳过、其余关联查询照常执行，同时引擎记录一条 `render related query` 规则上下文错误，并带上 `query_ref="<关联查询名称>"`。恢复查询表达式只要含 `{{` 就会被当作"含变量"，按实例渲染后执行，而不是作为静态表达式只执行一次。
+
### 关联查询 (Enrichment)
为了丰富告警通知的内容，可以配置"关联查询"。关联查询不参与告警判定，仅用于获取额外信息。
- **场景**：CPU 告警时，同时查询该机器的 `mem_usage_percent` 负载情况，展示在告警详情中，辅助排查。
-- **变量**：关联查询中支持 `${label_name}` 变量，用于针对具体告警对象查询。
+- **变量**：关联查询中支持 `${label_name}` 变量，也支持 Go 模板 `{{ $labels.<标签名> }}`（需 monit-edge `v0.75.4` 或以上），用于针对具体告警对象查询；两种写法的限制与渲染规则见上文「标签与变量」。
+- **渲染失败**：某条关联查询表达式渲染失败时，该条查询被跳过、其余关联查询继续执行，并记录 `render related query` 规则上下文错误。
- **结果展示**：关联查询的结果可以在告警规则的备注描述中引用，其变量是 `$relates`，您可以查看 **备注描述** 的详细使用说明。
diff --git a/zh/monitors/alert-rules/sls.mdx b/zh/monitors/alert-rules/sls.mdx
index 7263dadf9..f231a6792 100644
--- a/zh/monitors/alert-rules/sls.mdx
+++ b/zh/monitors/alert-rules/sls.mdx
@@ -49,7 +49,7 @@ Monitors 按配置的时间范围执行 SLS 查询，按标签字段区分告警
|------|------|
| **自动恢复** | 当数值不再满足任何告警阈值时，自动恢复 |
| **特定恢复条件** | 配置恢复表达式（如 `$A.error_cnt < 5`） |
-| **恢复查询** | 独立 SQL 用于恢复判定，支持 `${label_name}` 变量 |
+| **恢复查询** | 独立 SQL 用于恢复判定，支持 `${label_name}` 变量；亦支持 Go 模板 `{{ $labels.<标签名> }}`（需 monit-edge `v0.75.4` 及以上） |
| **手工关闭** | 告警保持活动，直到用户手工关闭 |
## 数据存在模式
diff --git a/zh/monitors/alert-rules/victorialogs.mdx b/zh/monitors/alert-rules/victorialogs.mdx
index 2cf6c2d6e..43c74dbb5 100644
--- a/zh/monitors/alert-rules/victorialogs.mdx
+++ b/zh/monitors/alert-rules/victorialogs.mdx
@@ -87,7 +87,7 @@ total{level="ERROR"} 150
|------|------|
| **自动恢复** | 当数值不再满足任何告警阈值时，自动生成恢复事件 |
| **特定恢复条件** | 配置恢复表达式（如 `$A.total < 10`），减少抖动 |
-| **恢复查询** | 独立查询用于恢复判定，支持 `${label_name}` 变量 |
+| **恢复查询** | 独立查询用于恢复判定，支持 `${label_name}` 变量；亦支持 Go 模板 `{{ $labels.<标签名> }}`（需 monit-edge `v0.75.4` 及以上） |
| **手工关闭** | 告警保持活动，直到用户手工关闭 |
## 数据存在模式 (Data Exists)
diff --git a/zh/on-call/advanced/war-room.mdx b/zh/on-call/advanced/war-room.mdx
index a11992931..afe975973 100644
--- a/zh/on-call/advanced/war-room.mdx
+++ b/zh/on-call/advanced/war-room.mdx
@@ -148,13 +148,13 @@ Flashduty App 支持完整的作战室生命周期，与控制台和 IM 应用
## AI SRE
-作战室与 **AI SRE** 深度联动：作战室创建后，AI SRE 会自动进行一轮初步诊断并把结论回贴到群里；您也可以在群聊中 **@ AI SRE** 继续追问或发起新的排查。详见 [AI SRE 产品介绍](/zh/ai-sre)与 [IM 平台](/zh/ai-sre/im)。
+作战室与 **AI SRE** 深度联动：您可以在群聊中 **@ AI SRE** 继续追问或发起新的排查；若已存在启用中的 [AI SRE 自动化规则](/zh/ai-sre/automations)，其触发方式为 **作战室创建触发** 且匹配该故障的协作空间与严重程度，作战室创建后该规则会自动在群里进行一轮初步诊断并把结论回贴到群聊。详见 [AI SRE 产品介绍](/zh/ai-sre)与 [IM 平台](/zh/ai-sre/im)。
### 作战室中的 AI SRE
<CardGroup cols={2}>
<Card title="自动初步诊断" icon="robot">
- 作战室创建后自动分析故障并回贴第一轮结论——人还没开始排查，第一手分析已经在群里
+ 启用中的 **作战室创建触发** 自动化规则匹配到该故障的协作空间与严重程度时，作战室创建后会在群里自动分析故障并回贴第一轮结论——人还没开始排查，第一手分析已经在群里
</Card>
<Card title="群内追问" icon="comment-dots">
在群聊中 @ AI SRE 发起或续接排查，Agent 在线程内回答，团队成员全程可见
diff --git a/zh/on-call/comparison/vs-opsgenie.mdx b/zh/on-call/comparison/vs-opsgenie.mdx
index 9dcd7a213..2b13e8951 100644
--- a/zh/on-call/comparison/vs-opsgenie.mdx
+++ b/zh/on-call/comparison/vs-opsgenie.mdx
@@ -124,7 +124,7 @@ Response 解决「找到人之后怎么快速闭环」：一条时间线、一
| --- | --- | --- |
| **AI 摘要与复盘** | 内置 AI 故障摘要、AI 一键生成复盘 | 无对等能力 |
| **自治排障 Agent** | [AI SRE](/zh/ai-sre)：接入真实环境的自治 Agent loop，云端沙箱 + 自托管 Runner 动态执行诊断命令，可通过 Skills、MCP、Subagent 与 A2A 无上限扩展；账户有已启用的 Monitors 数据源时，可经告警引擎**直连数据源查询**（内置 monit-query Skill，无需 Runner） | 无对等能力 |
-| **IM 原生排障** | 飞书/钉钉/企微/Slack [群聊 @ 召唤、私聊排障](/zh/ai-sre/im)，作战室创建后自动发起初步诊断 | 无对等能力 |
+| **IM 原生排障** | 飞书/钉钉/企微/Slack [群聊 @ 召唤、私聊排障](/zh/ai-sre/im)，作战室创建后，由匹配的自动化规则自动发起初步诊断 | 无对等能力 |
| **计费** | 按 credits 用量计费（1 credit = ¥1），开通免费，每个计费周期赠送体验额度 | — |
### 平台与集成
diff --git a/zh/on-call/comparison/vs-pagerduty.mdx b/zh/on-call/comparison/vs-pagerduty.mdx
index dbeec11d3..19b0ccccb 100644
--- a/zh/on-call/comparison/vs-pagerduty.mdx
+++ b/zh/on-call/comparison/vs-pagerduty.mdx
@@ -150,9 +150,9 @@ Response 解决「找到人之后怎么快速闭环」：一条时间线、一
| --- | --- | --- |
| **产品形态** | 自治 SRE Agent：对话式排障 + 自主规划执行 + 知识沉淀 | AIOps 事件降噪/关联；Advance 生成式 AI 助手（摘要、问答、复盘草稿）；四个预置 AI Agent 各管一段：SRE（诊断+预配置修复）、Scribe（会议记录）、Shift（排班）、Insights（数据问答） |
| **排障与修复方式** | 云端沙箱 + 自托管 [Runner（BYOC）](/zh/ai-sre/environments)，在您的环境中动态执行诊断命令、查询监控与日志，**可排查未预设过的问题**；账户有已启用的 Monitors 数据源时，可经告警引擎**直连数据源查询**（内置 monit-query Skill，无需 Runner） | SRE Agent 可自动分析日志/指标并匹配历史事件；修复动作依赖**预先配置**的 Automation Actions 脚本 |
-| **IM 原生协同** | 飞书/钉钉/企业微信/Slack [群聊 @ 召唤、私聊排障](/zh/ai-sre/im)，**作战室创建后自动发起初步诊断** | Slack、Teams 为主，无国内 IM |
+| **IM 原生协同** | 飞书/钉钉/企业微信/Slack [群聊 @ 召唤、私聊排障](/zh/ai-sre/im)，**作战室创建后，由匹配的自动化规则自动发起初步诊断** | Slack、Teams 为主，无国内 IM |
| **代码仓库与 K8s** | [GitHub/GitLab App](/zh/ai-sre/apps) 沙箱内访问代码仓库、提交 PR/MR/Issue；Kubernetes App 按 namespace 接入集群 | 公开资料未见 |
-| **AI 自动化任务** | [自动化](/zh/ai-sre/automations)按 cron、HTTP API 或故障事件触发，内置告警噪音分析、事故复盘、值班洞察等模板；On-call 故障触发支持**相似故障合并分析**（相似度 ≥0.9 并入进行中的分析会话） | 依赖 Event Orchestration 与 Runbook Automation 独立产品线 |
+| **AI 自动化任务** | [自动化](/zh/ai-sre/automations)按 cron、HTTP API、故障事件或作战室创建触发，内置告警噪音分析、事故复盘、值班洞察等模板；On-call 故障触发支持**相似故障合并分析**（相似度 ≥0.9 并入进行中的分析会话） | 依赖 Event Orchestration 与 Runbook Automation 独立产品线 |
| **可扩展性** | [Skills 市场](/zh/ai-sre/skills)、[MCP 外部工具](/zh/ai-sre/mcp)、[Subagent 与 A2A 委派](/zh/ai-sre/agents)，**扩展面不设上限** | SRE Agent 限于启停官方预置连接器（Datadog、Splunk、CloudWatch 等约 23 个）与追加提示词式 Skill；不支持为自家 Agent 挂载任意 MCP 工具，无子 Agent 派生，跨厂商 Agent 协作尚在 early access |
| **知识与记忆** | [知识](/zh/ai-sre/knowledge)（DUTY.md + 文件引用）、[自动记忆提炼](/zh/ai-sre/memory)，`/init` 可导入 Claude Code、Cursor 等工具的已有知识 | 公开资料未见 |
| **AI 复盘** | 故障复盘一键生成 + 自动化定时复盘 | 复盘（原 Jeli，正并入主产品）随 Professional 及以上提供，Professional/Business 档限每年 300 次 |
diff --git a/zh/on-call/integration/instant-messaging/dingtalk.mdx b/zh/on-call/integration/instant-messaging/dingtalk.mdx
index f56dd97bf..3bf7af2c9 100644
--- a/zh/on-call/integration/instant-messaging/dingtalk.mdx
+++ b/zh/on-call/integration/instant-messaging/dingtalk.mdx
@@ -202,13 +202,14 @@ keywords: ["钉钉", "即时消息", "告警通知", "IM集成", "钉钉机器
## AI SRE 控制项
-在 **增强功能** 中配置以下 AI SRE 控制项，默认均为开启：
+在 **增强功能** 中配置以下 AI SRE 控制项，默认开启：
-- **自动发起 AI 故障分析**：需先开启作战室才会出现；作战室创建成功后，自动发起一次 AI 故障分析。
- **允许在 IM 中使用 AI SRE**：无需开启作战室即可配置。开启后，可在该集成接入的群聊中 @ AI SRE，或在机器人私聊中直接发起对话；关闭后这两个入口都不会触发 AI SRE 回复。
如果账户尚未启用 AI SRE，以上配置暂不生效。
+作战室创建后的自动 AI 故障分析不在本页配置：如需在作战室创建时自动发起一次，请在 [自动化](/zh/ai-sre/automations) 中新建一条规则，触发方式选择 **作战室创建触发**，并选好要监听的协作空间与严重程度。
+
<span id="publish"></span>
## 应用发布与使用
diff --git a/zh/on-call/integration/instant-messaging/lark.mdx b/zh/on-call/integration/instant-messaging/lark.mdx
index d71c46fcf..42fe1da34 100644
--- a/zh/on-call/integration/instant-messaging/lark.mdx
+++ b/zh/on-call/integration/instant-messaging/lark.mdx
@@ -140,12 +140,13 @@ keywords: ["飞书", "Lark", "即时消息", "告警通知", "IM集成"]
在 **增强功能** 中分别配置以下 AI SRE 控制项，默认均为开启：
-- **自动发起 AI 故障分析**：开启作战室后可配置；作战室创建成功后，自动发起一次 AI 故障分析。
- **允许在 IM 中使用 AI SRE**：无需开启作战室即可配置。开启后，可在该集成接入的群聊中 @ AI SRE，或在机器人私聊中直接发起对话；关闭后这两个入口都不会触发 AI SRE 回复。
- **普通群聊中 AI SRE 使用话题回复**：无需开启作战室即可配置。开启后，普通群聊中的每个话题对应一个独立 Session；作战室仍直接在群内回复。
如果账户尚未启用 AI SRE，以上配置暂不生效。
+作战室创建后的自动 AI 故障分析不在本页配置：如需在作战室创建时自动发起一次，请在 [自动化](/zh/ai-sre/automations) 中新建一条规则，触发方式选择 **作战室创建触发**，并选好要监听的协作空间与严重程度。
+
## 关联用户
在集成详情页的 **关联用户** 页签中，您可以查看团队成员与飞书账号的关联状态，并快速完成批量关联。
diff --git a/zh/on-call/integration/instant-messaging/slack.mdx b/zh/on-call/integration/instant-messaging/slack.mdx
index 0f900b718..daadc4e2a 100644
--- a/zh/on-call/integration/instant-messaging/slack.mdx
+++ b/zh/on-call/integration/instant-messaging/slack.mdx
@@ -34,12 +34,13 @@ keywords: ["Slack", "即时消息", "告警通知", "IM集成", "协作工具"]
在 **增强功能** 中分别配置以下 AI SRE 控制项，默认均为开启：
-- **自动发起 AI 故障分析**：开启作战室后可配置；作战室创建成功后，自动发起一次 AI 故障分析。
- **允许在 IM 中使用 AI SRE**：无需开启作战室即可配置。开启后，可在已接入的 Slack 群聊中 @ AI SRE、使用 `/fd` 命令，或在机器人私聊中直接发起对话；关闭后这三种入口都不会触发 AI SRE 回复。
- **普通群聊中 AI SRE 使用话题回复**：无需开启作战室即可配置。开启后，普通群聊中的每个话题对应一个独立 Session；作战室仍直接在群内回复。
如果账户尚未启用 AI SRE，以上配置暂不生效。
+作战室创建后的自动 AI 故障分析不在本页配置：如需在作战室创建时自动发起一次，请在 [自动化](/zh/ai-sre/automations) 中新建一条规则，触发方式选择 **作战室创建触发**，并选好要监听的协作空间与严重程度。
+
## 关联用户
在集成详情页的 **关联用户** 页签中，您可以查看团队成员与 Slack 账号的关联状态，并快速完成批量关联。
diff --git a/zh/on-call/integration/instant-messaging/wecom.mdx b/zh/on-call/integration/instant-messaging/wecom.mdx
index 57aed7575..028b72da5 100644
--- a/zh/on-call/integration/instant-messaging/wecom.mdx
+++ b/zh/on-call/integration/instant-messaging/wecom.mdx
@@ -120,9 +120,8 @@ Flashduty 作为企业微信服务商，为您提供 Flashduty 应用的长期
## AI SRE 控制项
-以下 AI SRE 控制项在集成配置页面的 **增强功能** 模块中配置，默认均为开启：
+以下 AI SRE 控制项在集成配置页面的 **增强功能** 模块中配置，默认开启：
-- **自动发起 AI 故障分析**：需先开启作战室才会出现；作战室创建成功后，自动发起一次 AI 故障分析。
- **允许在 IM 中使用 AI SRE**：无需开启作战室即可配置，同时控制该集成的群聊 @ AI SRE 与机器人私聊两个入口；关闭后对应入口不会触发 AI SRE 回复。
企业微信的两种应用模式对 AI SRE 入口的支持不同。**允许在 IM 中使用 AI SRE** 在两种模式下都会显示，集成详情预览页也会展示其状态：
@@ -134,6 +133,8 @@ Flashduty 作为企业微信服务商，为您提供 Flashduty 应用的长期
如果账户尚未启用 AI SRE，以上配置暂不生效。
+作战室创建后的自动 AI 故障分析不在本页配置：如需在作战室创建时自动发起一次，请在 [自动化](/zh/ai-sre/automations) 中新建一条规则，触发方式选择 **作战室创建触发**，并选好要监听的协作空间与严重程度。
+
## 配置 AI SRE 智能机器人
在企业微信单聊或群聊中 @ 智能机器人，即可发起 AI SRE 排障会话，无需离开企业微信。智能机器人只能在 **企业自建应用** 模式下配置。
diff --git a/zh/rum/sdk/android/data-collection.mdx b/zh/rum/sdk/android/data-collection.mdx
index a0f19ba13..fc862506d 100644
--- a/zh/rum/sdk/android/data-collection.mdx
+++ b/zh/rum/sdk/android/data-collection.mdx
@@ -174,6 +174,7 @@ RUM 可以从用户的 IP 地址推断出地理位置信息：
| `geo.country` | string | 国家名称 |
| `geo.country_iso` | string | 国家的 ISO 代码 |
| `geo.city` | string | 城市名称 |
+| `geo.province` | string | 省份名称，仅中国 IP 有值。由后端根据上报 IP 推断（不由 SDK 上报），使用英文省名（如 `Guangdong`、`Inner Mongolia`）；城市未知时仍可能有值 |
<Note>
地理位置信息由 Flashduty 后端根据客户端 IP 地址推断，不会在 Android 客户端收集精确的 GPS 位置，也不需要定位权限。
diff --git a/zh/rum/sdk/ios/data-collection.mdx b/zh/rum/sdk/ios/data-collection.mdx
index cad8b929a..e952d01f8 100644
--- a/zh/rum/sdk/ios/data-collection.mdx
+++ b/zh/rum/sdk/ios/data-collection.mdx
@@ -107,6 +107,7 @@ iOS RUM SDK 为所有事件自动附加默认属性，帮助您了解用户设
| `geo.continent_code` | 字符串 | 洲的 ISO 代码（如 `EU`、`AS`） |
| `geo.continent` | 字符串 | 洲名称 |
| `geo.city` | 字符串 | 城市名称 |
+| `geo.province` | 字符串 | 省份名称，仅中国 IP 有值。由后端根据上报 IP 推断（不由 SDK 上报），使用英文省名（如 `Guangdong`、`Inner Mongolia`）；城市未知时仍可能有值 |
<Note>
地理位置信息由 Flashduty 后端根据客户端 IP 地址推断，不会在客户端收集精确的 GPS 位置。
diff --git a/zh/rum/sdk/web/data-collection.mdx b/zh/rum/sdk/web/data-collection.mdx
index ee531d077..1704bd804 100644
--- a/zh/rum/sdk/web/data-collection.mdx
+++ b/zh/rum/sdk/web/data-collection.mdx
@@ -71,6 +71,7 @@ Web RUM SDK 会自动捕获以下默认属性，这些属性适用于所有 RUM
| `geo.continent_code` | 字符串 | 洲的 ISO 代码（如 `EU`、`AS`、`NA`） |
| `geo.continent` | 字符串 | 洲名称 |
| `geo.city` | 字符串 | 城市名称 |
+| `geo.province` | 字符串 | 省份名称，仅中国 IP 有值。由后端根据上报 IP 推断（不由 SDK 上报），使用英文省名（如 `Guangdong`、`Inner Mongolia`）；城市未知时仍可能有值 |
<Note>
地理位置信息由 FlashCat 后端根据客户端 IP 地址推断，不会在客户端收集精确的 GPS 位置。