@@ -43,6 +43,23 @@ The artifact gallery has no entry point for manually uploading or creating files
 - **Search box**: fuzzy-search published artifacts by title; the query fires automatically 300ms after you stop typing.
 - **Scope**: a three-way **All / Personal / Team** switch (the same two-level scope shared with the other resources under AI SRE). Selecting "Team" expands a searchable, multi-select team picker; selecting no team means "all teams visible to me."
 
+### View toggle and sorting
+
+The top-right of the list page offers a **Card view / List view** toggle; your choice is persisted in the browser (card view is the default).
+
+**List view** presents artifacts in a table with these columns:
+
+| Column | Description |
+|---|---|
+| Name | Artifact title; click to open the detail page |
+| Scope | Team name for team artifacts, creator name for personal artifacts |
+| From conversation | Title of the source conversation; click to jump to it. Shows plain text "Conversation deleted" when the source conversation was deleted or has no title |
+| Created at | Artifact creation time |
+| Updated at | Artifact last-updated time |
+| Actions | Rename, download, delete, etc. |
+
+The **Created at** and **Updated at** columns support header sorting (ascending / descending toggle); sorting is executed server-side, with **Updated at descending** as the default.
+
 ### Artifact cards
 
 Each card shows:
 
@@ -162,6 +162,18 @@ After the switch, AI SRE:
 Knowledge bundles already mounted into this session are not removed — mounts are conversation-scoped, so switching back to a previously-mounted team will not duplicate the mount reminder.
 </Note>
 
+## /feedback — Rate an AI SRE Reply
+
+---
+
+Once an AI SRE reply lands in a group chat, anyone in the group can rate it — not only whoever started the investigation. Send `/feedback` to the bot to rate or comment on the reply you are looking at:
+
+- **Entry and resolution:** `/feedback` is backed by the AI SRE side (POST /safari/session/latest-reply → POST /safari/feedback/create); it resolves "the message you are looking at" into the corresponding reply event even if you never took part in that conversation.
+- **Eligibility:** **not limited to session members** — any account member who can use AI SRE may rate (read-only group-chat readers included); an AI SRE answer posted into a group chat is public, and the reader who spotted the error is exactly whose opinion we want.
+- **How to rate:** choose `like` / `dislike` / `none`; a comment-only submission (no rating) is allowed and does not wipe an earlier rating you gave, while an explicit `none` clears the existing rating.
+- **Stored per rater:** each reply is keyed by **(reply event, rater)** — when several people rate the same reply, each gets its own row and they do not overwrite one another.
+- **Console side:** the console conversation header also offers thumbs-up feedback on replies (see [Feedback](/en/ai-sre/sessions#feedback)), sharing the same rating system as IM `/feedback`.
+
 ## Relationship to Console Sessions
 
 ---
 
@@ -264,7 +264,66 @@ The preview panel provides **Copy**, **Download**, and **Close** actions.
 Report-type artifacts (such as operational insight reports) can be generated as HTML containing Mermaid diagrams and charts, viewable directly in the rendered view. For operational insight capabilities, see <a href="/en/ai-sre/insight">Operational Insight Reports</a>.
 </Tip>
 
-All published artifacts can also be viewed and managed in one place on the **Artifacts** page in the left navigation (list, search, filter by personal / team scope, rename, download, and delete) — see <a href="/en/ai-sre/artifacts">Artifacts</a>.
+All published artifacts can also be viewed and managed in one place on the **Artifacts** page in the left navigation (list, search, filter by personal / team scope, card / list view toggle, sort by created / modified time, rename, download, and delete) — see <a href="/en/ai-sre/artifacts">Artifacts</a>.
+
+### Status Page Update Drafts
+
+The agent can call the `statuspage_draft` tool to **draft** an announcement for your public status page — a new incident or maintenance event, or an update appended to an existing event. Drafts are saved server-side and rendered in the conversation as a **status page update draft card**; but a draft is **never published automatically**: publishing a status page reaches subscribers immediately and cannot be recalled, so that step is always left to a human — review each item in the status page publish form in the console, then click publish.
+
+#### What's on the draft card
+
+The card reuses the visuals, field order, and component status icons of the console's corresponding cards (IncidentCard / MaintenanceCard), so what reviewers see is exactly what will be published:
+
+| Content | Description |
+|---|---|
+| Title | For a new event, the form's `name` field (backend `title`, up to 255 characters); for an appended update, the title of the event it attaches to — the append-update form has no title field, so this serves as identification only (shows "Untitled status page update" when not provided) |
+| Status / scheduled time | New maintenance shows "Scheduled for 〈start〉 → 〈end〉" (shows "No schedule set" when unset); otherwise the status text — incidents: Investigating / Identified / Monitoring / Resolved; appended maintenance updates: Scheduled / Ongoing / Completed |
+| Body | The `message` field is **fully rendered** as Markdown — this is what customers will read; reviewers must see the whole picture, and it must not appear as plain text |
+| Affected components | One chip per component: component status icon + name (hover shows "name · status") |
+| Target & type | Bottom left shows "Will publish to 〈status page〉" (appended updates show "Update · 〈event title〉"); the right side labels the type: Incident / Maintenance |
+| Warning banner | If the draft message contains Markdown the status page editor doesn't support and that would be **silently dropped** when loaded into the form (headings, code blocks, block quotes, images, strikethrough, inline code), the card lists each one in a warning banner — already detected by the tool at draft time |
+
+#### Card states
+
+| State | Behavior |
+|---|---|
+| Drafting | Skeleton screen, with "Drafting status page update…" at the bottom |
+| Tool error | "Failed to generate draft" + the specific reason; you can ask the AI to try again, or create it manually on the status page |
+| Incomplete draft | "Incomplete draft" + the same hint (the tool returned a result but no usable draft object) |
+| Ready to review | Button is **Review →**: opens the corresponding status page form in the console in a new tab, with the draft content pre-filled (URL convention below) |
+| Published | Button becomes a disabled **Published**; the bottom target becomes a link to the **published change** (`/status-page/{page_id}?menu=incidents\|maintenance&incident\|maintenance={change_id}`), so you can look back at what the draft eventually became |
+| Draft expired / not found | Button becomes a disabled **Draft expired**, with "Draft expired or not found — ask the AI to draft a new one" — treated the same when the console query returns ResourceNotFound or a network error |
+
+Whether it has been published is a fact the card cannot observe on its own (publishing happens in the console, in another tab), so the card queries `GET /status-page/draft/info?draft_id=...` by draft ID, which returns `status: pending | published`. While the draft is still pending, it refreshes every time the window regains focus ("review here, publish there, come back" is the normal path); `published` and "draft not found" are both terminal states, and the result is cached for the lifetime of the current page. Read-only shared sessions don't render the review button, and the draft status query is skipped as well.
+
+#### Handoff URL for review
+
+The draft itself lives server-side (fc-statuspage's draft storage); only the `draft_id` crosses over to the console: the form pulls the body from `/status-page/draft/info` by ID. The URLs combine into four variants by "new / append" × "incident / maintenance":
+
+| Scenario | URL |
+|---|---|
+| New incident | `/status-page/{page_id}?menu=incidents&incident=new&draft={draft_id}` |
+| New maintenance | `/status-page/{page_id}?menu=maintenance&maintenance=new&draft={draft_id}` |
+| Append incident update | `/status-page/{page_id}?menu=incidents&incident={change_id}&action=add-update&draft={draft_id}` |
+| Append maintenance update | `/status-page/{page_id}?menu=maintenance&maintenance={change_id}&action=add-update&draft={draft_id}` |
+
+`action=add-update` makes the detail page auto-expand the append-update form; without it, the route only opens the event itself and the draft is never read. `?draft=` carries only the draft ID — the draft is server-side state, not a chunk of JSON in the URL.
+
+#### Tool specifics
+
+| Field | Description |
+|---|---|
+| `page_id` / `page_name` | Target status page (required) and its display name (used on the card) |
+| `type` | `incident` (incident) / `maintenance` (maintenance) |
+| `change_id` | Omitted = new event; set = append an update to that event. Before drafting, the tool first checks `fduty status-page list` and `fduty status-page change-active-list` — if the target already has an active event, it should append rather than open another one (a second event reads to customers as another separate outage) |
+| `title` / `message` | Title for a new event (≤255 characters) and the body (required, Markdown; the status page editor keeps only bold, italic, links, bulleted / numbered lists, tables, and `---` dividers) |
+| `status` | New incident: `investigating` / `identified` / `monitoring` / `resolved`; new maintenance: omit (whether it advances on schedule is decided by the publish form's toggle); appended maintenance update: `scheduled` / `ongoing` / `completed` |
+| `affected_components` | Affected components (`component_id` + `status`, optionally with display name `name`); incident component status: `operational` / `degraded` / `partial_outage` / `full_outage`, maintenance component status: `operational` / `under_maintenance` |
+| `start_at_seconds` / `end_at_seconds` | Only for a new maintenance: planned window start and end, unix **seconds** (milliseconds and ISO strings are treated as invalid) |
+
+<Note>
+Channel differences: the console (`web`) and automation channels render the card above; IM and API channels don't render cards — instead the agent puts a "[Review & publish](〈the same handoff URL〉)" link at the **start of the reply**, then summarizes the draft points in a sentence or two (IM message truncation doesn't parse Markdown, so the link comes first to be safe). If saving the draft failed (no `review_url`), it falls back to a text summary and points you to the status page in the console to verify manually.
+</Note>
 
 ### Message Actions
 
 
@@ -93,6 +93,29 @@ Member rows in the member list and inside team detail pages are now clickable, o
 - Profiles and roles of SSO-synced members are maintained by the identity provider; the in-page edit entries stay locked
 
 See [Teams and Members](/en/platform/team-members).
+<Update label="2026-09-01" description="🔕 Silence detection for alert integrations, AI SRE status page drafts, and IM feedback">
+
+### Silence detection for alert integrations
+
+Alert integrations (standard/Email/IM/Flashcat, etc.) add a **silence detection** setting:
+
+- When enabled, if an integration receives no valid event within the specified window (10 minutes to 48 hours, default 10 minutes), a Warning alert is generated
+- "Auto-recover on new event" is on by default; the alert recovers as soon as the next event passes integration validation
+
+### AI SRE status page drafts
+
+AI SRE conversations can call the **statuspage_draft** tool to draft status page incident/maintenance updates:
+
+- Drafts are previewed in chat as cards (title, status, body, affected components)
+- The AI only drafts and never publishes; the draft link opens the console publish form (prefilled via `?draft=<id>`) for human review and release
+- Draft states include pending review and published; a swept or unknown draft link shows as expired in the console
+
+### IM feedback and ratings
+
+Use **/feedback** in a work group chat to rate or comment on AI SRE replies:
+
+- You can submit a comment only without choosing a rating; ratings support like/dislike/none
+- Each member's ratings are stored independently
 
 </Update>
 
 
@@ -52,6 +52,14 @@ When the query type includes logs, a log time distribution chart appears above t
 - 24 hours – 30 days: requires manual click to load.
 - Beyond 30 days: not supported.
 
+### Log View
+
+Log-type query results are displayed row by row; each row contains the timestamp, body, and a field summary. If a batch of results contains fields whose value is identical in every row (common fields, such as Loki's stream labels), these fields are shown in the summary on every row by default, but they take up width on each row repeatedly.
+
+- The **Common Fields** button on the toolbar lists the fields that are identical across every row in the current batch, with their values; after checking **Hide Inline** in the popover, these common fields are collapsed out of the inline summary, and each row keeps only the content that differs (with a "+N fields" hint displayed)
+- **Hide Inline** is off by default (common fields are shown by default); the toggle is session state, not persisted — refreshing the page restores the default
+- Clicking a row expands its details; the details always show all fields of that row, unaffected by the **Hide Inline** toggle
+
 ## Query Parameters
 
 In addition to the query expression, some data sources support private parameters:
 
@@ -84,6 +84,8 @@ Determines how users are reached.
 
     <Info>
     **Cross-team webhook address scoping.** When selecting a Webhook bot address in a dispatch policy, addresses are grouped by ownership tier: **Current Channel** (already referenced by this channel), **Same Team** (referenced by other channels in the same team), and **Other Team** (referenced only by channels in other teams). Other-team addresses are collapsed by default and require manual expansion. Selecting an other-team address shows a **Cross-team** badge and warning; on save, a confirmation modal appears when cross-team addresses are present, preventing alerts from being sent to another team's chat by accident.
+
+    When selecting or pasting a Webhook address from **Other Team**, the alias automatically gets a prefix of the source team name (e.g. `team-name-alias`; if an existing alias already starts with that prefix, it is not applied again, and when pasting, the prefix is added only if the alias is empty). After the prefix is added, the alias can still be modified manually.
     </Info>
   </Tab>
 </Tabs>
 
@@ -121,7 +121,7 @@ If you've snoozed and the snooze time has passed but you still haven't resolved
 
 <Tabs>
 <Tab title="Snooze via Console">
-Click incident details in console, click **Snooze** button, select snooze duration, done.
+Click incident details in console, click **More (⋮)** in the top-right, choose the **Snooze** submenu, select snooze duration, done. Only incidents in the Processing state can be snoozed.
 </Tab>
 
 <Tab title="Snooze via IM App">
@@ -186,7 +186,10 @@ The **More** button at the top right of the incident details page groups supplem
 | :--- | :--- |
 | **Merge into Incident** | Merge the current incident into another target incident; after the merge, alerts from both incidents are consolidated and handled within the target incident |
 | **Quick Silence** | Jump to the alert silence configuration page of the incident's channel with key fields of the current incident pre-filled, so you can quickly create a targeted silence rule |
+| **Snooze** | Only shown when the incident is in the Processing state. Opens a Snooze submenu where you pick a preset duration or a custom one; see [Snooze](#snooze). Not shown once the incident is closed or not in Processing |
+| **Escalate** | Only shown when an escalation policy is enabled and the incident is not yet closed. Escalates the incident to a specific step of the escalation chain (the steps used for per-level escalation); the selected step's responder takes over |
 | **Unacknowledge** | Only shown if you have acknowledged and the incident is not yet closed; used to revoke a prior acknowledgment. Once all responders have unacknowledged, the incident reverts to **Triggered** |
+| **Reassign** | Only shown when the incident is not closed. Opens a reassign dialog to hand the incident to another member |
 | **Invite Followers to War Room** | Only shown if a war room has been created for the incident; lets you pull additional members into the corresponding IM war room group |
 | **Close War Room** | Only shown if a war room has been created for the incident; closes the IM war room group. See [War Room](/en/on-call/advanced/war-room) for details |
 | **Custom Actions** | Jira, ServiceNow, ServiceDesk Plus, and general custom actions configured by administrators in integrations |
 
@@ -62,6 +62,7 @@ By default, the system creates a new alert for every email, but you can switch t
 
    - You must fill in at least one **trigger** rule
    - You must set regex extraction rules for Alert Key. The system uses this field to find historical alerts for updates or closure; **if regex extraction fails, the system will use the email subject to generate an Alert Key** to ensure alerts aren't lost due to configuration errors
+   - The Alert Key regex must be a valid RE2 expression. It is validated when the rule is saved; an illegal expression is rejected with the message "Please enter a valid regex"
    - You can choose whether to discard emails when no rules match
 
    Configuration example:
@@ -71,6 +72,16 @@ By default, the system creates a new alert for every email, but you can switch t
 
    <img src="https://download.flashcat.cloud/flashduty/integration/email/send-mode.png" alt="drawing" width="800"/>
 
+#### Silence Detection
+
+In the integration card (edit and preview), the **Silence Detection** (Heartbeat) setting sits below the push settings: if no valid event arrives within the configured interval, the system generates a Warning alert.
+
+| Setting | Description |
+| :--- | :--- |
+| **Enable Silence Detection** | Switch, off by default. When on, only upstream events that pass integration validation refresh the detection time |
+| **Detection Interval (minutes)** | A Warning alert is generated if no valid event arrives within this interval. Must be an integer between 10 minutes and 48 hours (default 10 minutes) |
+| **Auto-recover on new event** | Switch, on by default. When the next valid event arrives, the alert raised by silence detection is recovered automatically |
+
 ### Important Notes
 
 1. The system will reject emails larger than 5MB
 
@@ -159,6 +159,18 @@ Nightingale supports configuring global webhook URLs in both the interface and c
 
 </div>
 
+## Silence Detection
+
+---
+
+In the integration card (edit and preview), the **Silence Detection** (Heartbeat) setting is available below the alert push settings: if no valid event arrives within the configured interval, the system generates a Warning alert.
+
+| Setting | Description |
+| :--- | :--- |
+| **Enable Silence Detection** | Switch, off by default. When on, only upstream events that pass integration validation refresh the detection time |
+| **Detection Interval (minutes)** | A Warning alert is generated if no valid event arrives within this interval. Must be an integer between 10 minutes and 48 hours (default 10 minutes) |
+| **Auto-recover on new event** | Switch, on by default. When the next valid event arrives, the alert raised by silence detection is recovered automatically |
+
 ## Severity Mapping
 ---