debidong · Oct 10, 2026 · Oct 9, 2026 · Oct 9, 2026 · Oct 9, 2026 · Oct 9, 2026
diff --git a/docs.json b/docs.json
diff --git a/en/ai-sre.mdx b/en/ai-sre.mdx
@@ -51,16 +51,7 @@ It is not a question-and-answer chatbot but a **hands-on troubleshooter**, integ
 
 ## Activation and billing
 
-AI SRE is available to accounts on an On-call Pro or higher subscription, with no application needed.
-
-<AccordionGroup>
-  <Accordion title="Billing" icon="gift">
-    AI SRE is billed on actual usage starting September 16, 2026, 08:00 Beijing time, settled in credits (1 credit = ¥1); usage before that date isn't charged. Metered items are model usage, sandbox online time, and web search. Activation is free, eligible accounts get gift credits each billing period, and you can also buy credit packages (1,000 / 5,000 / 20,000 credits for ¥950 / ¥4,500 / ¥17,000, valid 365 days from payment). Pay-as-you-go is off by default; an admin can turn it on and optionally set a per-period cap. Full terms: [AI SRE Credit Package Purchase Agreement](/en/compliance/ai-sre-credit-package-purchase-agreement).
-  </Accordion>
-  <Accordion title="Human authorization" icon="user-check">
-    Production changes, restarts, rollbacks, and external notifications all require your confirmation before they execute.
-  </Accordion>
-</AccordionGroup>
+AI SRE must be activated in the console and is billed on actual usage in credits. Production changes, restarts, rollbacks, and external notifications all require your confirmation before they execute. For activation, billing rules, and subscription requirements, see [Activation and billing](/en/ai-sre/overview#activation-and-billing).
 
 ## Get Started
 

diff --git a/en/ai-sre/agents.mdx b/en/ai-sre/agents.mdx
diff --git a/en/ai-sre/apps.mdx b/en/ai-sre/apps.mdx
@@ -5,22 +5,16 @@ keywords: ["AI SRE", "Apps", "App", "GitHub", "GitHub App", "GitLab", "GitLab Ap
 sidebarTitle: Apps
 ---
 
-<Info>
-  AI SRE is available to accounts on an On-call Pro or higher subscription, with no application needed. Starting September 16, 2026, 08:00 Beijing time, it must be activated in the console before use and is billed on actual usage; see [billing terms](/en/compliance/ai-sre-credit-package-purchase-agreement).
-</Info>
+> AI SRE must be activated in the console, is available on On-call Pro or higher, and is billed on actual usage. See [Activation and billing](/en/ai-sre/overview#activation-and-billing).
 
 ## Overview
 
----
-
 **Apps** is where you manage **authorized external applications**. Each external application appears as a **card** — you authorize it, manage its installations, and enable / disable or revoke it right from its card.
 
 Apps includes **GitHub**, **GitLab**, and **Kubernetes Apps**. GitHub and GitLab authorize access to code repositories: AI SRE can read code, investigate changes / commits / PRs (MRs on GitLab), and, when asked, fix a bug or open a PR / MR or issue. A Kubernetes App connects a selected Kubernetes cluster to AI SRE and limits the agent to the configured namespaces and permission level.
 
 ## Main Scenario: Letting the Cloud Sandbox Reach Your Repositories
 
----
-
 AI SRE sessions run in a **Flashduty cloud sandbox** by default. The sandbox is a clean, isolated, ephemeral environment that **carries none of your git credentials** — which is exactly what an App solves. Once you authorize the GitHub App or the GitLab App, the agent inside the sandbox can clone your repositories, read diffs, and open PRs / MRs, **without you handing it any password or token**; its access is limited to the repositories you granted, with only the least privilege needed to do the work. **This is what both Apps are mainly for.**
 
 <Note>
@@ -33,8 +27,6 @@ A RUM application can also record the repositories that build it (several may be
 
 ## Where to Find It
 
----
-
 Go to **AI SRE → Customize → Plugins → Apps**. The Plugins group in the Customize sidebar lists Overview / Apps / Skill / MCP / Agents in that order, and clicking **Customize** opens **Overview** by default.
 
 <Note>
@@ -43,8 +35,6 @@ Viewing the Apps page requires the appropriate permission; without it, the entry
 
 ## Kubernetes Apps
 
----
-
 A Kubernetes App connects an in-cluster agent to AI SRE. After installation, AI SRE can query cluster information and use the available Kubernetes tools within the namespaces and permission boundaries you configure.
 
 ### Create and install
@@ -87,7 +77,7 @@ Operations that differ between levels:
 | Modify RBAC within the namespace | No | No | Yes |
 | Operate cluster-scoped resources and cluster RBAC | No | No | All namespaces only |
 
-- **Read-only**: read access within the authorized namespaces is bound directly to Kubernetes' built-in `view` role — FlashDuty no longer maintains its own resource list. It covers Pods, logs, workloads, events, ConfigMaps, and similar resources, but never Secrets; CRDs that cluster components mark as view-readable are included as well. It also grants read-only access to cluster-level nodes, namespaces, persistentvolumes, storageclasses, and ingressclasses.
+- **Read-only**: read access within the authorized namespaces is bound directly to Kubernetes' built-in `view` role — Flashduty no longer maintains its own resource list. It covers Pods, logs, workloads, events, ConfigMaps, and similar resources, but never Secrets; CRDs that cluster components mark as view-readable are included as well. It also grants read-only access to cluster-level nodes, namespaces, persistentvolumes, storageclasses, and ingressclasses.
 - **Read + limited modifications**: on top of read-only, this level may evict Pods (`pods/eviction`), scale Deployments and StatefulSets (`deployments/scale`, `statefulsets/scale`), and adjust HPA replica bounds (`horizontalpodautoscalers`). These rules can only change how many replicas a workload runs and rebuild Pods from the same configuration — they cannot change any Pod's image, startup command, environment variables, identity, or mounts. As a result, `kubectl rollout restart` and `kubectl rollout undo` are both denied (in Kubernetes both are patches to the workload); restart a workload by evicting its Pods one at a time. For rollbacks, AI SRE derives the target revision from the ReplicaSet history and gives you the complete `kubectl rollout undo --to-revision=N` command to run in your cluster.
 - **Full access**: can read Secrets, modify ConfigMaps and Secrets, modify workload configurations, create or delete resources, and modify RBAC within the namespace; **All namespaces + Full access** additionally grants `cluster-admin` via a `ClusterRoleBinding`, covering cluster-scoped resources and cluster RBAC.
 
@@ -97,39 +87,31 @@ You can edit the cluster name, scope, and namespace access from the Kubernetes A
 
 ## The GitHub App
 
----
-
 The following walks through **GitHub** first — authorization, installation management, and adjusting repository access; **GitLab** follows in the next section.
 
 ### Connecting a GitHub Organization
 
-Start the authorization from the GitHub card. The whole install completes in a popup through GitHub's official install page, and the list refreshes automatically after the callback.
+Authorization happens on GitHub's official install page, opened in a popup.
 
 <Steps>
   <Step title="Start the authorization">
-    Click **Authorize** on the GitHub card (if the App already has an installation, the button reads **More repositories**, with a + icon). The frontend opens a popup that loads GitHub's official install page.
+    Click **Authorize** on the GitHub card (**More repositories** if the App is already installed) and continue on the GitHub install page that pops up.
   </Step>
   <Step title="Pick the organization and repositories on GitHub">
     Choose the **organization** (or personal account) to install into, and grant a repository scope — **All repositories** or **Only select repositories**. The set of granted repositories determines which repositories AI SRE can access afterward.
   </Step>
   <Step title="Auto-refresh after you confirm">
-    After you confirm on GitHub, the popup closes automatically, the Apps page shows **Authorized** and refreshes the installation list, and the new organization appears.
+    After you confirm on GitHub, the popup closes and the new organization appears in the installation list.
   </Step>
 </Steps>
 
 <Note>
-If you are not the owner of the organization, GitHub routes the request to the organization owner through its request-to-install approval flow; the installation activates only after approval. Which organization to install into and which repositories to grant are decided entirely on GitHub's install page — Flashduty does not select on your behalf.
+If you are not an owner of the organization, GitHub sends the request to the organization owner for approval; the installation takes effect once approved.
 </Note>
 
 ### Managing Installations
 
-Each authorized organization adds one installation row under the GitHub card. Each row shows:
-
-| Element | Description |
-|---|---|
-| Organization name | The GitHub organization / account login the installation lives on |
-| Status dot | A colored dot plus a label: **Connected**, **Suspended**, **Revoked** |
-| Repository count | The number of repositories currently granted to this installation |
+Each authorized organization adds a row under the GitHub card, showing the organization name, status (**Connected**, **Suspended**, **Revoked**) and the number of repositories granted.
 
 <AccordionGroup>
   <Accordion title="Enable / Disable (suspend / resume)" icon="toggle-on">
@@ -154,9 +136,7 @@ The organization is already connected, but you want AI SRE to reach more of its
 
 ## The GitLab App
 
----
-
-The **GitLab** App connects a GitLab instance — **GitLab.com**, **JihuLab** (GitLab's China distribution, SaaS at jihulab.com or a private deployment), or any other **self-managed** instance of your own. The connection method is **exactly the same for all of them**: register an OAuth application on that instance first, then authorize. Once authorized, AI SRE can read code and investigate changes / MRs, and — when you ask — file an issue or open an MR, in the repositories you authorized. Just like GitHub, **you never paste a personal token**: once Flashduty gets an OAuth grant, it provisions a dedicated bot identity for your account to do the actual work.
+The **GitLab** App connects **GitLab.com**, **JihuLab** (jihulab.com SaaS or a private deployment) or any other **self-managed** instance, the same way for all: register an OAuth application on the instance, then authorize. AI SRE can then read code and investigate changes / MRs in the authorized repositories, and file issues or open MRs when you ask. As with GitHub, **you never paste a personal token**; Flashduty provisions a dedicated bot identity for your account.
 
 ### Connecting a GitLab Instance
 
@@ -174,10 +154,9 @@ The **GitLab** App connects a GitLab instance — **GitLab.com**, **JihuLab** (G
   <Step title="Register an OAuth application on that instance">
     The connect wizard shows a **copyable Redirect URI**. Take it to the GitLab instance you entered and create an OAuth application: a group **Owner** does this under **Group Settings → Applications**; on **GitLab.com**, if you're not the Owner of any group, a user-owned application under **User Settings → Applications** also works; an instance admin can also register one under **Admin Area → Applications**. Fill in the Redirect URI the wizard gave you, check **Confidential**, and check only the **api** scope. GitLab then issues an **Application ID** and a **Secret** — paste both back into the wizard.
 
-    <Tip>This step is the same for **every** GitLab instance — GitLab.com, JihuLab (jihulab.com SaaS or a private deployment), or any other self-managed instance: only the address changes, registering the OAuth application and pasting the Application ID / Secret works identically everywhere.</Tip>
   </Step>
   <Step title="Authorize in the popup">
-    This step shows which instance and which OAuth application it's about to authorize with; if you want to use a different application, click **Change OAuth application** to go back and register a different one. Once you confirm, the wizard opens a popup that loads GitLab's official authorization page; sign in with your GitLab account and confirm. The popup closes automatically once authorization completes, and the wizard advances to the next step.
+    Confirm the instance and OAuth application to use (click **Change OAuth application** to switch), then sign in and confirm on the GitLab authorization page that pops up.
   </Step>
   <Step title="Pick the groups and projects to authorize">
     AI SRE shows a repository picker listing the **groups where you have the Owner role** and the **projects where you have the Maintainer role**. Select the groups / projects you want AI SRE to access and save — selecting a group covers all of its projects, including ones created later.
@@ -192,7 +171,7 @@ An account can connect **only one** GitLab instance at a time (GitLab.com or one
 
 After you save the repository selection, Flashduty provisions a dedicated bot for the account inside those groups / projects (a service account where the instance supports it, falling back to a group- or project-level access token otherwise) for AI SRE sessions to use. Either way, the bot's permissions are capped at **Developer** level — the same minimum access you'd grant it in GitLab yourself. Tokens are **rotated automatically** before they expire; there's nothing for you to manage.
 
-If the instance doesn't support service accounts, the bot falls back to a group- or project-level token — and a token like that can only ever bind to a single group or project, so the repository picker limits you to selecting at most **one** group or project. If you select multiple groups / projects while in multi-select mode and save, Flashduty shows "This GitLab instance doesn't support service accounts; select only one group or project and retry," and switches the picker to **single-select mode**: checking a new group or project after that automatically clears any other selection, so you need to leave just one group or project checked before saving again.
+If the instance does not support service accounts, the bot uses a group- or project-level token instead, and you can select only **one** group or project.
 
 <Warning>
 **One restriction on GitLab.com**: GitLab's own policy limits group- and project-level access tokens to **paid (non-free, non-trial) namespaces**. Connecting GitLab.com itself is unaffected, but if the group / project you authorize lives in a free or trial namespace, bot provisioning fails and the UI shows GitLab's own explanation ("provisioning_denied"). Upgrade that namespace to a paid plan and re-authorize to resolve it.
@@ -213,8 +192,6 @@ The GitLab card shows the connected instance's address and status.
 
 ## How AI SRE Works Inside a Repository
 
----
-
 After authorization, you need no extra configuration. When you ask AI SRE to work on a task in a repository during a session, it works like an engineer joining the project — understand first, then change, then verify. This behavior is governed by the built-in `github` Skill and `gitlab` Skill respectively.
 
 **Typical actions**
@@ -235,21 +212,17 @@ If the agent reports it cannot access a repository in a cloud session, it usuall
 
 ## Permissions & Scope
 
----
-
-**Authorize** and **revoke / disconnect** are **account-level** operations for both the GitHub App and the GitLab App. **The account is the only security boundary**; the team here is just an ownership / audit tag: any account member with the corresponding permission can authorize, revoke / disconnect, or enable / disable the whole App; when a session needs a repository, it obtains access from the account's currently active installation. Members of an account share one authorization — consistent with AI SRE's "usage = account-level, ownership = team tag" model for other resources.
+Authorizing and revoking / disconnecting the GitHub App and GitLab App are **account-level** operations: any member with the relevant permission can do them, members share one authorization, and sessions access repositories through the account's currently active installation. Teams are only an ownership tag; **the account is the only security boundary**.
 
 The two Apps' scope models differ slightly: the **GitHub App** lets the same account install multiple organizations, each enabled / revoked independently; the **GitLab App** lets an account connect **only one** GitLab instance **at a time** — switching to a different instance requires disconnecting the current one first.
 
 ## Related Pages
 
----
-
 <CardGroup cols={2}>
   <Card title="MCP (External Tools)" icon="plug" href="/en/ai-sre/mcp">
     Connect external tools and data sources via the Model Context Protocol.
   </Card>
-  <Card title="Console" icon="comments" href="/en/ai-sre/sessions">
+  <Card title="Console Chat" icon="comments" href="/en/ai-sre/sessions">
     Watch the agent clone a repo, read a diff, and open a PR / MR during a session.
   </Card>
   <Card title="Environments (BYOC)" icon="server" href="/en/ai-sre/environments">