Merge pull request #228 from flashcatcloud/doc-review/2026-07-29-194515

docs: sync doc-review findings (2026-07-29)

Author: ysyneu

en/ai-sre/agents.mdx

@@ -77,7 +77,7 @@ On the A2A Agents list page, click **Add A2A Agent** and fill in the form:
 | Streaming | bool | on | Whether to communicate with the remote agent in streaming mode |
 | User Auth Mode | enum | `shared` | See "Auth Modes" below |
 | Skip TLS certificate verification | bool | off | Shown only when the Card URL uses HTTPS. Enable only when the remote endpoint uses a self-signed certificate inside a controlled network; this skips certificate-chain and hostname verification |
-| Allow OAuth discovery over HTTP | bool | off | Required only when "Per-user OAuth" is selected and the Card URL is a non-local HTTP URL. Use only in controlled test environments; after you enable it, the Safari service can fetch OAuth metadata from that host |
+| Allow OAuth discovery over HTTP | bool | off | Required only when "Per-user OAuth" is selected and the Card URL is a non-local HTTP URL. Use only in controlled test environments; after you enable it, the AI SRE service can fetch OAuth metadata from that host |
 
 ### Using the FlashAI Template
 
@@ -199,8 +199,8 @@ The full lifecycle of A2A agents is managed on the **Plugins → Agents** page.
   <Accordion title="Delete" icon="trash">
     Remove an A2A agent from the current scope. **Active sessions that delegated to it will fail.** Deletion requires confirmation.
   </Accordion>
-  <Accordion title="Filter by scope" icon="filter">
-    The scope filter bar at the top of the list lets you switch between "All", "Account only", and "Specific team", making it easy to focus on relevant resources when managing many. Each row also has a label showing its scope (account / team name).
+  <Accordion title="Filter by scope and search" icon="filter">
+    The scope filter bar at the top of the list lets you switch between "All", "Account only", and "Specific team", making it easy to focus on relevant resources when managing many. Each row also has a label showing its scope (account / team name). The search box to the right of the filter bar filters the list by keywords in the name, instructions, or Card URL.
   </Accordion>
 </AccordionGroup>
 

en/ai-sre/mcp.mdx

@@ -164,7 +164,7 @@ OAuth authorization completes through a browser **bounce page** at `/oauth-callb
 
 ---
 
-The MCP list displays each server's **name** (including its AI description), **scope** (account or team name), **transport**, an **enabled** toggle, and an **actions** column — the list only contains MCP servers you have added to the account; the built-in Flashduty MCP server is injected by the runtime and does not appear in this list, see "Inspection" below. The scope filter bar at the top lets you switch between All / Account / Team views.
+The MCP list displays each server's **name** (including its AI description), **scope** (account or team name), **transport**, an **enabled** toggle, and an **actions** column — the list only contains MCP servers you have added to the account; the built-in Flashduty MCP server is injected by the runtime and does not appear in this list, see "Inspection" below. The scope filter bar at the top lets you switch between All / Account / Team views, and the search box to its right filters the list by keywords in the name, description, transport, or URL.
 
 <AccordionGroup>
   <Accordion title="Enable / Disable" icon="toggle-on">

en/ai-sre/sessions.mdx

@@ -1,6 +1,6 @@
 ---
 title: Console
-description: An AI SRE session holds one complete conversation between you and the agent, including messages, streaming responses, tool calls, and artifacts. This page covers creating and managing sessions, sending messages, previewing artifacts, session forking, context compaction, team binding, and session data export.
+description: An AI SRE session holds one complete conversation between you and the agent, including messages, streaming responses, tool calls, and artifacts. This page covers creating and managing sessions, sharing, sending messages, previewing artifacts, session forking, context compaction, team binding, and session data export.
 keywords: ["AI SRE", "session", "chat", "streaming response", "tool call", "Artifacts", "Fork", "context compaction", "team binding", "export", "NDJSON"]
 sidebarTitle: Console
 ---
@@ -61,6 +61,24 @@ The account is the hard access boundary for sessions: sessions are never accessi
 
 Pinning is a personal preference and does not modify the session itself; if you can read a session, you can pin or unpin it for yourself. Account owners and admins can manage team sessions, but they cannot read or manage another member's personal session.
 
+### Sharing a Session
+
+The chat page header provides share controls, shown only when you have manage permission on the current session. Click the **Copy share link** button to enable sharing and copy the link to your clipboard (a "Share link copied" toast appears). The link appends a `share_token` to the current session URL, with the token in the URL fragment (after `#`). The share link is **stable**: while sharing stays enabled, copying it again yields the same link.
+
+| Topic | Details |
+|---|---|
+| Who can share | Members with manage permission on the session — the creator of a personal session, or the creator / account owner / admin / team members of a team session |
+| Who can open it | Members who hold the link and are signed in to the **same account**; the link does not work across accounts or for anonymous visitors |
+| What link holders see | The session opens in **read-only** mode with a "This is a read-only shared session" notice: they can inspect the full context (messages, tool calls, artifacts), but the composer is replaced by the notice — they cannot continue the conversation or modify the original session |
+| How to keep working | Link holders can click **Fork into a new session** to derive their own session and continue from there |
+| How to revoke | Once sharing is enabled, a **Remove share** button appears in the header; clicking it invalidates the link immediately (a "Share removed" toast appears). Re-enabling sharing later generates a new link — the old link is not restored |
+
+Sharing mainly changes the visibility of **personal sessions**: a team session is already readable by any member of the same account who has the session ID (see the table above), whereas a personal session is visible only to its creator by default — a share link is the only way for other members of the account to open it.
+
+<Note>
+Incognito sessions and Subagent sessions cannot be shared.
+</Note>
+
 ### Per-Session Actions
 
 Hover over a session row to reveal the pin and archive actions. A pinned session displays a persistent pin icon to the left of its name.

en/ai-sre/skills.mdx

@@ -160,7 +160,7 @@ Skill archive size limits: archives saved by the agent in-conversation are cappe
 
 ---
 
-The skill list displays each skill's **name** (with source template badge and **Update available** marker), **scope** (account or team), **version**, **enabled** toggle, and an **actions** column.
+The skill list displays each skill's **name** (with source template badge and **Update available** marker), **scope** (account or team), **version**, **enabled** toggle, and an **actions** column. The toolbar above the list provides a scope filter (All / Account / Team) and a search box that filters the list by keywords in the name, description, or author.
 
 <AccordionGroup>
   <Accordion title="Enable / Disable" icon="toggle-on">

en/monitors/alert-rules/clickhouse.mdx

@@ -30,15 +30,14 @@ This mode is suitable for scenarios requiring threshold comparison on aggregated
     GROUP BY service_name
     ```
 2. **Field Mapping**:
-  - **Label Fields**: Fields used to distinguish different alert objects. In the above example, it's `service_name`. This field can be left empty; Monitors will automatically treat all fields except value fields as label fields.
-  - **Value Fields**: Numeric fields used for threshold evaluation. In the above example, it's `error_cnt`.
+  - **Value Fields**: Numeric fields used for threshold evaluation. In the above example, it's `error_cnt`. Monitors automatically treats fields other than the value fields in the query result as labels (`service_name` in the above example).
 3. **Threshold Conditions**:
   - Use `$A.field_name` to reference values.
   - Example: `Critical: $A.error_cnt > 50`, `Warning: $A.error_cnt > 10`.
 
 ### How It Works
 
-The engine executes the SQL query and gets the result set. It groups data by "label fields", then extracts "value fields" values to compare against threshold expressions.
+The engine executes the SQL query and gets the result set. It automatically groups data using fields other than the value fields as labels, then extracts the "value fields" values to compare against threshold expressions.
 
 ### Recovery Logic
 
@@ -113,6 +112,6 @@ ClickHouse is very sensitive to time partitions. Always include time range filte
 </Accordion>
 
 <Accordion title="Field Case">
-Monitors engine converts column names returned by ClickHouse to lowercase. When filling in "label fields" and "value fields", always use lowercase letters.
+Monitors engine converts column names returned by ClickHouse to lowercase. When filling in "value fields", always use lowercase letters.
 </Accordion>
 </AccordionGroup>

en/monitors/alert-rules/mysql.mdx

@@ -30,15 +30,14 @@ This mode is suitable for scenarios requiring threshold comparison on aggregated
     GROUP BY service_name
     ```
 2. **Field Mapping**:
-  - **Label Fields**: Fields used to distinguish different alert objects. In the above example, it's `service_name`. This field can be left empty; Monitors will automatically treat all fields except value fields as label fields.
-  - **Value Fields**: Numeric fields used for threshold evaluation. In the above example, it's `error_cnt`.
+  - **Value Fields**: Numeric fields used for threshold evaluation. In the above example, it's `error_cnt`. Monitors automatically treats fields other than the value fields in the query result as labels (`service_name` in the above example).
 3. **Threshold Conditions**:
   - Use `$A.field_name` to reference values.
   - Example: `Critical: $A.error_cnt > 50`, `Warning: $A.error_cnt > 10`.
 
 ### How It Works
 
-The engine executes SQL query and gets the result set. It groups data by "label fields", then extracts "value fields" values to compare against threshold expressions.
+The engine executes SQL query and gets the result set. It automatically groups data using fields other than the value fields as labels, then extracts the "value fields" values to compare against threshold expressions.
 
 ### Recovery Logic
 
@@ -105,6 +104,6 @@ Recommended syntax: `log_time > now() - INTERVAL 5 MINUTE`
 </Accordion>
 
 <Accordion title="Field Case">
-Monitors engine converts column names returned by MySQL to lowercase. When filling in "label fields" and "value fields", always use lowercase letters.
+Monitors engine converts column names returned by MySQL to lowercase. When filling in "value fields", always use lowercase letters.
 </Accordion>
 </AccordionGroup>

en/monitors/alert-rules/oracle.mdx

@@ -30,15 +30,14 @@ This mode is suitable for scenarios requiring threshold comparison on aggregated
     GROUP BY service_name
     ```
 2. **Field Mapping**:
-  - **Label Fields**: Fields used to distinguish different alert objects. In the above example, it's `service_name`. This field can be left empty; Monitors will automatically treat all fields except value fields as label fields.
-  - **Value Fields**: Numeric fields used for threshold evaluation. In the above example, it's `error_cnt`.
+  - **Value Fields**: Numeric fields used for threshold evaluation. In the above example, it's `error_cnt`. Monitors automatically treats fields other than the value fields in the query result as labels (`service_name` in the above example).
 3. **Threshold Conditions**:
   - Use `$A.field_name` to reference values.
   - Example: `Critical: $A.error_cnt > 50`, `Warning: $A.error_cnt > 10`.
 
 ### How It Works
 
-The engine executes SQL query and gets the result set. It groups data by "label fields", then extracts "value fields" values to compare against threshold expressions.
+The engine executes SQL query and gets the result set. It automatically groups data using fields other than the value fields as labels, then extracts the "value fields" values to compare against threshold expressions.
 
 ### Recovery Logic
 
@@ -105,6 +104,6 @@ Recommended syntax: `log_time > SYSDATE - INTERVAL '5' MINUTE`
 </Accordion>
 
 <Accordion title="Field Case">
-Monitors engine converts column names returned by Oracle to lowercase. When filling in "label fields" and "value fields", always use lowercase letters.
+Monitors engine converts column names returned by Oracle to lowercase. When filling in "value fields", always use lowercase letters.
 </Accordion>
 </AccordionGroup>

en/monitors/alert-rules/postgres.mdx

@@ -30,15 +30,14 @@ This mode is suitable for scenarios requiring threshold comparison on aggregated
     GROUP BY service_name
     ```
 2. **Field Mapping**:
-  - **Label Fields**: Fields used to distinguish different alert objects. In the above example, it's `service_name`. This field can be left empty; Monitors will automatically treat all fields except value fields as label fields.
-  - **Value Fields**: Numeric fields used for threshold evaluation. In the above example, it's `error_cnt`.
+  - **Value Fields**: Numeric fields used for threshold evaluation. In the above example, it's `error_cnt`. Monitors automatically treats fields other than the value fields in the query result as labels (`service_name` in the above example).
 3. **Threshold Conditions**:
   - Use `$A.field_name` to reference values.
   - Example: `Critical: $A.error_cnt > 50`, `Warning: $A.error_cnt > 10`.
 
 ### How It Works
 
-The engine executes SQL query and gets the result set. It groups data by "label fields", then extracts "value fields" values to compare against threshold expressions.
+The engine executes SQL query and gets the result set. It automatically groups data using fields other than the value fields as labels, then extracts the "value fields" values to compare against threshold expressions.
 
 ### Recovery Logic
 
@@ -105,6 +104,6 @@ Recommended syntax: `log_time > NOW() - INTERVAL '5 minutes'`
 </Accordion>
 
 <Accordion title="Field Case">
-Monitors engine converts column names returned by PostgreSQL to lowercase. When filling in "label fields" and "value fields", always use lowercase letters.
+Monitors engine converts column names returned by PostgreSQL to lowercase. When filling in "value fields", always use lowercase letters.
 </Accordion>
 </AccordionGroup>

en/monitors/alert-rules/sls.mdx

@@ -31,15 +31,14 @@ This mode is suitable for scenarios requiring threshold comparison on aggregated
   - `sls.timespan.value`: (Optional) Time span value, default is 15.
   - `sls.timespan.unit`: (Optional) Time span unit, supports `s` (seconds), `m` (minutes), `h` (hours), `d` (days). Default is `m`.
 3. **Field Mapping**:
-  - **Label Fields**: Fields used to distinguish different alert objects. In the above example, it's `host`. This field can be left empty; Monitors will automatically treat all fields except value fields as label fields.
-  - **Value Fields**: Numeric fields used for threshold evaluation. In the above example, it's `error_cnt`.
+  - **Value Fields**: Numeric fields used for threshold evaluation. In the above example, it's `error_cnt`. Monitors automatically treats fields other than the value fields in the query result as labels (`host` in the above example).
 4. **Threshold Conditions**:
   - Use `$A.field_name` to reference values.
   - Example: `Critical: $A.error_cnt > 50`, `Warning: $A.error_cnt > 10`.
 
 ### How It Works
 
-The engine calls SLS API, specifying time range (like last 15 minutes), executing SQL query. After getting results, it groups by "label fields", extracts "value fields" to compare against thresholds.
+The engine calls SLS API, specifying time range (like last 15 minutes), executing SQL query. After getting results, it automatically groups data using fields other than the value fields as labels, then extracts "value fields" to compare against thresholds.
 
 ### Recovery Logic
 

en/monitors/alert-rules/victorialogs.mdx

@@ -18,7 +18,6 @@ Calls `/select/logsql/query` interface, returning two-dimensional table data.
 | Query Statement | e.g., `error \| fields _time, _stream, _msg \| sort by (_time) desc` |
 | Return Limit | Limit maximum returned rows, max can be set to 100 |
 | Time Range | Specify query time window, e.g., "last 5 minutes" |
-| Label Fields | Used to distinguish different alert entities, can configure multiple |
 | Value Fields | Required in threshold evaluation mode |
 </Tab>
 
@@ -57,7 +56,7 @@ Result looks like:
 |-------|-------|
 | ERROR | 150   |
 
-Configure value field as `total`, label field as `level` (or leave empty, Monitors will auto-detect). Different threshold different level configuration examples:
+Configure the value field as `total`; Monitors automatically recognizes fields other than the value fields (`level` in the above example) as labels. Different threshold different level configuration examples:
 
 - Warning: `$A.total >= 50` or shorthand `$A >= 50` (since there's only one value field: total)
 - Critical: `$A.total >= 100` or shorthand `$A >= 100` (since there's only one value field: total)