Merge pull request #143 from flashcatcloud/doc-review/20260706-031624

docs: sync doc-review drift findings

Author: ysyneu

en/ai-sre/automations.mdx

@@ -19,7 +19,7 @@ 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, and trigger it on demand from an external system with a `POST`, passing the context for this run in the request body.
-- **On-call incident trigger (API)**: subscribe to selected On-call integrations and severities through the Automation API, then start a diagnostic run when a matching incident appears.
+- **On-call incident trigger**: select the On-call channels and severities to watch, then start a diagnostic run when a matching incident appears.
 
 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.
 
@@ -67,7 +67,7 @@ For **Environment**, "Auto" has the backend pick the best available environment
 
 ---
 
-A rule must have **at least one trigger** configured. The current console form exposes **Schedule** and **Call via API** in the "Triggers" section, and both can be enabled at the same time; the public API also supports an On-call incident trigger for wiring incident events directly into Automation runs.
+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.
 
 ### Schedule (cron)
 
@@ -132,22 +132,32 @@ The `text` in the request body is passed to the agent as context for this run, o
 A rule can enable **both** "Schedule" and "Call via API" at the same time: it runs automatically on the cadence and can also be kicked off on demand from outside. Each trigger occupies its own row and can be **removed** independently.
 </Tip>
 
-### On-call Incident Trigger (API)
+### On-call Incident Trigger
 
-Use the Automation API to configure an `oncall_incident` trigger when you want AI SRE to start automatically from On-call incidents. The trigger registers a subscription with the On-call side, and only incidents matching the selected integrations and severities start a run.
+Add the **On-call incident** trigger when you want AI SRE to start automatically from On-call incidents. The trigger registers a subscription with the On-call side, and only incidents matching the selected channels and severities start a run.
+
+<Steps>
+  <Step title="Add the trigger">
+    Click the **On-call incident** card in "Triggers". The form expands channel and severity conditions.
+  </Step>
+  <Step title="Select channels">
+    Select the On-call 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.
+  </Step>
+  <Step title="Select severities">
+    Select one or more severities from `Critical`, `Warning`, and `Info`. When this trigger is enabled, at least one channel and one severity are required.
+  </Step>
+</Steps>
+
+If you create or update a rule through the API, use these fields:
 
 | Field | Type | Notes |
 |---|---|---|
 | `oncall_incident_trigger_enabled` | boolean | Whether the On-call incident trigger is enabled. |
-| `oncall_incident_channel_ids` | int64[] | On-call integration IDs to watch. Creating or enabling this trigger requires at least one valid ID. |
+| `oncall_incident_channel_ids` | int64[] | On-call channel IDs to watch. Creating or enabling this trigger requires at least one valid ID. |
 | `oncall_incident_severities` | string[] | Incident severities to watch. Supported values are `Critical`, `Warning`, and `Info`; creating or enabling this trigger requires at least one value. |
 
 When a matching event arrives, the system creates a run with `trigger_kind: "oncall_incident"` and passes event context such as `incident_id`, `channel_id`, and `severity` into the session. The same trigger and the same `incident_id` reuse the same run, avoiding duplicate hidden sessions for one incident.
 
-<Note>
-The current console form does not expose a separate On-call incident trigger card. Configure it with the Automation create / update APIs in the API reference.
-</Note>
-
 ## Run History
 
 ---

en/ai-sre/environments.mdx

@@ -19,14 +19,14 @@ AI SRE provides two types of Environments:
 
 <CardGroup cols={2}>
   <Card title="Cloud Sandbox" icon="cloud" href="/en/ai-sre/sandbox">
-    A Flashduty-managed temporary container that works out of the box with no install. When no BYOC Runner is online, sessions automatically fall back to the cloud Sandbox.
+    A Flashduty-managed temporary container that works out of the box with no install. When no usable BYOC Runner is online for the current member, sessions automatically fall back to the cloud Sandbox.
   </Card>
   <Card title="BYOC Runner" icon="server" href="#byoc-runner">
     A persistent process deployed on your own machine. It connects to AI SRE over WebSocket and lets the agent execute inside your network boundary.
   </Card>
 </CardGroup>
 
-The default selection logic is: **if the account has an online BYOC Runner, AI SRE uses a Runner first; otherwise it uses the cloud Sandbox.** You can also pin a session to the cloud Sandbox, or to a specific Runner, from the environment selector in the chat input.
+The default selection logic is: **AI SRE uses an online BYOC Runner that the current member can use first; otherwise it uses the cloud Sandbox.** Usable Runners include account-scoped Runners and team-scoped Runners that belong to one of the current member's teams. You can also pin a session to the cloud Sandbox, or to a specific Runner, from the environment selector in the chat input.
 
 <Note>
 The console record is called an **Environment**. The process running on your machine is called a **Runner**. One BYOC Environment maps to one Runner process; cloud Sandbox instances are managed by the system per session.
@@ -321,9 +321,9 @@ The environment selector at the bottom of the chat input decides where a new ses
 
 | Option | Meaning |
 |---|---|
-| **Auto** | The default for new sessions. Uses an online Runner if the account has one; otherwise falls back to the cloud Sandbox. |
+| **Auto** | The default for new sessions. Uses an online Runner the current member can use; otherwise falls back to the cloud Sandbox. |
 | **Cloud Sandbox · Default** | Forces the system-managed cloud Sandbox and ignores self-hosted Runners. |
-| **Self-hosted Environment** | Lists visible Runners. Offline or never-connected Runners appear disabled and cannot be selected. |
+| **Self-hosted Environment** | Lists Runners the current member can use. Offline, never-connected, or team-mismatched Runners cannot be selected. |
 
 <Warning>
 Environment selection is locked once per session: the Environment determined when the session sends its first message is recorded and reused for all later turns. Changing the selector afterward does not change that session. To switch environments, start a new session.
@@ -339,8 +339,8 @@ Each BYOC Environment has account-level or team-level scope:
 
 | Scope | Visibility |
 |---|---|
-| Account | Visible to all members in the account. |
-| Team | Visible and editable only by members of that team. |
+| Account | Visible, selectable, and usable by all members in the account. |
+| Team | Visible, editable, selectable, and usable only by members of that team. |
 
 Edit permissions follow the unified rule:
 
@@ -349,7 +349,7 @@ Edit permissions follow the unified rule:
 3. There is no "creator extra permission"; you do not need to be the creator if the rules above allow the edit.
 
 <Note>
-Scope is an editing and ownership label, while the account is the runtime security boundary. When auto-selecting a Runner, the system chooses from online BYOC Runners in the account by matching tags. Team scope mainly controls who can see and edit the Runner in the console.
+The account remains the runtime security boundary, but team scope also participates in Runner selection. When the system auto-selects a Runner, or when a session is pinned to a Runner by ID, it only uses account-scoped Runners or team-scoped Runners that belong to one of the current member's teams. This prevents a member from landing a session on a team Runner they cannot use.
 </Note>
 
 ## Troubleshooting

en/ai-sre/sandbox.mdx

@@ -1,6 +1,6 @@
 ---
 title: Sandbox
-description: The cloud sandbox is a Flashduty-managed, temporary execution environment that works out of the box with no install. When no self-hosted Runner is online, AI SRE sessions run in the cloud sandbox by default; you can also pin a session to it manually.
+description: The cloud sandbox is a Flashduty-managed, temporary execution environment that works out of the box with no install. When no usable self-hosted Runner is online for the current member, AI SRE sessions run in the cloud sandbox by default; you can also pin a session to it manually.
 keywords: ["AI SRE", "cloud sandbox", "Sandbox", "environment", "fallback", "egress", "BYOC"]
 sidebarTitle: Sandbox
 ---
@@ -15,7 +15,7 @@ sidebarTitle: Sandbox
 
 The **cloud sandbox** is a **temporary execution environment** managed by Flashduty — an isolated, ready-to-use container. The AI SRE agent's tool calls (running commands, reading and writing files, running Skills, connecting to MCP) all happen inside it, and you **don't have to install or maintain anything**.
 
-It is AI SRE's **default fallback**: when your account has no online self-hosted Runner ([BYOC Runner](/en/ai-sre/environments#byoc-runner)), sessions automatically run in the cloud sandbox; you can also **pin a session to it manually**.
+It is AI SRE's **default fallback**: when no usable self-hosted Runner ([BYOC Runner](/en/ai-sre/environments#byoc-runner)) is online for the current member, sessions automatically run in the cloud sandbox; you can also **pin a session to it manually**.
 
 <CardGroup cols={2}>
   <Card title="Zero install, ready to use" icon="cloud">
@@ -48,7 +48,7 @@ The **environment selector** at the bottom of the chat box decides where the ses
 
 | Option | Behavior |
 |---|---|
-| **Auto** | The default for new sessions. Prefers an online Runner if the account has one; otherwise **falls back to the cloud sandbox**. |
+| **Auto** | The default for new sessions. Prefers an online Runner the current member can use; otherwise **falls back to the cloud sandbox**. |
 | **Cloud sandbox · Default** | Forces the cloud sandbox, ignoring all self-hosted Runners. |
 
 <Note>

en/developer/cli.mdx

@@ -376,9 +376,9 @@ Common flags:
 
 ### Full command coverage
 
-Beyond the curated commands above, the CLI now provides **full coverage** of the Flashduty OpenAPI through a spec-driven code generator. The current OpenAPI contains **288 API operations**, and the CLI generates corresponding resource-organized commands for them. In addition to the On-call domain (incident, change, channel, field, status-page, template, and more), it also covers:
+Beyond the curated commands above, the CLI now provides **full coverage** of the Flashduty OpenAPI through a spec-driven code generator. The current OpenAPI contains **291 API operations**, and the CLI generates corresponding resource-organized commands for them. In addition to the On-call domain (incident, incident-trigger-subscription, change, channel, field, status-page, template, and more), it also covers:
 
-- **AI SRE (`safari`)**: a2a-agents, mcp-servers, sessions, skills, and more
+- **AI SRE (`safari`)**: a2a-agents, automations, mcp-servers, sessions, skills, and more
 - **Alerting & noise reduction**: alert, alert-event, enrichment (alert-rules, rule-sets), route
 - **On-call & scheduling**: calendar, schedule
 - **Platform administration**: account, member, person, team, role (roles-permissions), audit (audit-logs)

en/developer/go-sdk.mdx

@@ -1,7 +1,7 @@
 ---
 title: Go SDK
 sidebarTitle: Go SDK
-description: "go-flashduty is the official open-source Go SDK for Flashduty — a typed, strictly 1:1 wrapper over the Open API currently covering all 288 API operations across 32 services."
+description: "go-flashduty is the official open-source Go SDK for Flashduty — a typed, strictly 1:1 wrapper over the Open API currently covering all 291 API operations across 32 services."
 keywords: ["Go SDK", "go-flashduty", "Open API", "Golang", "client"]
 ---
 
@@ -11,7 +11,7 @@ keywords: ["Go SDK", "go-flashduty", "Open API", "Golang", "client"]
 
 `go-flashduty` is the official open-source Go client for Flashduty, covering every REST endpoint of the Flashduty Open API. It follows the same design as [go-github](https://github.com/google/go-github) — service groups, typed requests and responses, a composable transport layer — and stays strictly 1:1 with the OpenAPI spec: each method maps to exactly one HTTP call, returns `(*T, *Response, error)`, and performs no implicit cross-endpoint aggregation or enrichment.
 
-The SDK currently covers **288 API operations** across **32 services**, all generated from the Flashduty OpenAPI spec, covered by unit tests, and end-to-end verified against the live API.
+The SDK currently covers **291 API operations** across **32 services**, all generated from the Flashduty OpenAPI spec, covered by unit tests, and end-to-end verified against the live API.
 
 <Note>
 The SDK is deliberately "thin." Consumer-side logic such as short-ID resolution and cross-endpoint orchestration belongs in the caller (CLI / MCP), not stuffed into the SDK or shoehorned into an endpoint. This keeps the SDK strictly one-to-one with the API — predictable, generatable, and verifiable.
@@ -163,10 +163,13 @@ Endpoints are grouped by service and hang off the client: the call convention is
 | `client.MonitorUtilities` | Monitor datasource preview |
 | `client.Analytics` | Analytics |
 | `client.A2aAgents` | A2A Agents |
+| `client.Automations` | AI SRE automations |
 | `client.McpServers` | MCP Servers |
 | `client.Sessions` | AI SRE sessions |
 | `client.Skills` | Skills |
 | `client.Applications` | RUM applications |
+| `client.DataQuery` | RUM data query |
+| `client.Facets` | RUM fields and facets |
 | `client.Issues` | RUM issues |
 | `client.Sourcemaps` | RUM sourcemaps |
 

en/developer/overview.mdx

@@ -58,7 +58,7 @@ See the [Command-line tool](/en/developer/cli) guide for the full installation m
 
 ## Go SDK
 
-go-flashduty is the official Go SDK for Flashduty. Built in the go-github style, it provides a typed wrapper over the Flashduty OpenAPI covering 288 API operations across 32 services, so you can call them directly from Go with full type safety and autocompletion.
+go-flashduty is the official Go SDK for Flashduty. Built in the go-github style, it provides a typed wrapper over the Flashduty OpenAPI covering 291 API operations across 32 services, so you can call them directly from Go with full type safety and autocompletion.
 
 The module is `github.com/flashcatcloud/go-flashduty` and requires Go 1.24+. Install with one command:
 

en/home.mdx

@@ -162,7 +162,7 @@ Integrate Flashduty through Open API and Webhooks for automation and custom deve
     Authentication, request specs, error handling
   </Card>
   <Card title="API Catalog" icon="list" href="/en/openapi/api-catalog">
-    All 288 endpoints organized by module
+    All 291 endpoints organized by module
   </Card>
   <Card title="About Pagination" icon="file-lines" href="/en/openapi/pagination">
     Traditional and cursor pagination

en/rum/sdk/web/sdk-integration.mdx

@@ -172,8 +172,8 @@ Whether to enable long task event collection
 Whether to enable cross-session anonymous user ID collection
 </ParamField>
 
-<ParamField body="sessionReplayPrivacyLevel" type="'allow' | 'mask-user-input' | 'mask-all'" default="mask-user-input">
-Session replay privacy policy: `allow` collects all data except passwords, `mask-user-input` hides user input field content, `mask-all` hides all text
+<ParamField body="sessionReplayPrivacyLevel" type="'allow' | 'mask-user-input' | 'mask'" default="mask-user-input">
+Session replay privacy policy: `allow` collects all data except passwords, `mask-user-input` hides user input field content, and `mask` hides all text
 </ParamField>
 
 <ParamField body="allowedTracingUrls" type="array">