docs(admin): re-verify on the Docker demo stack

platform/control-plane/access-control/access-explorer.md

@@ -6,7 +6,7 @@ sidebar_position: 5
 
 The **Access Explorer** answers "what can this person reach?" and "who can reach this object?" with full provenance: for every line it says whether the access is direct, comes through a group, or comes through workspace membership. Use it before you grant access, and when someone reports they can see (or cannot see) something.
 
-![The Access Explorer for member-sso: workspaces and shared objects, each with how the access arises](/img/platform/admin/cp-explorer-user.png)
+![The Access Explorer for alice.nguyen@egret.local: workspaces and shared objects, each with how the access arises](/img/platform/admin/cp-explorer-user.png)
 
 You need **role:read** to open the page. Two tabs switch the direction.
 
@@ -23,7 +23,7 @@ The result has two sections:
 | **Workspaces** | Each workspace the principal belongs to, with the workspace role and where it comes from. |
 | **Shared objects** | Each object shared with the principal: the kind (**dashboard**, **folder**, and so on), the name, the workspace, the role, the **allow** or deny effect and the source. |
 
-The source reads **direct** for access given to the person, or **via \<group\>** when it comes through a group. For example, member-sso holds `ws_viewer` on *Docs sandbox* directly and `ws_editor` through the group `data-team`, and shows the shared dashboard *Finance KPIs* via `data-team`.
+The source reads **direct** for access given to the person, or **via \<group\>** when it comes through a group. For example, alice.nguyen@egret.local holds `ws_admin` on *Docs sandbox* and *Finance analytics* directly, `ws_editor` on *Finance analytics* and `finance_reporter` on *Docs sandbox* via `finance-analysts`, and sees an app shared with that group.
 
 ## Object → who can access
 
@@ -33,7 +33,7 @@ The source reads **direct** for access given to the person, or **via \<group\>**
 
 ![Who can access the Finance KPIs dashboard, with the source of each line](/img/platform/admin/cp-explorer-object.png)
 
-The result lists every principal that can reach the object. The header shows the kind, name and workspace. A filter, *All sources (5)*, narrows by source. The columns are:
+The result lists every principal that can reach the object. The header shows the kind, name and workspace. A filter, *All sources (10)* for *Finance KPIs* on the demo stack, narrows by source. The columns are:
 
 | Column | Meaning |
 |---|---|

platform/control-plane/access-control/groups.md

@@ -6,7 +6,7 @@ sidebar_position: 2
 
 A **group** is a set of users you can give roles and grants to once instead of person by person. **Control Plane → Identity → Groups** lists local groups you create in egret and groups synced from your identity provider.
 
-![The Groups list showing two groups synced from OIDC](/img/platform/admin/cp-groups.png)
+![The Groups list: local groups and groups synced from OIDC](/img/platform/admin/cp-groups.png)
 
 You need **group:read** to open the page.
 
@@ -34,12 +34,12 @@ The dialog says *Create a local group.* After creating it, open the group to add
 
 ## The group page
 
-![A synced group with members and roles](/img/platform/admin/cp-group-detail.png)
+![The local group finance-analysts: details, three members and no roles](/img/platform/admin/cp-group-detail.png)
 
 | Section | What it holds |
 |---|---|
 | **Details** | The **Name** (editable for local groups). |
-| **Members** | *Members are synced from your identity provider* for a synced group, with **Member**, **Email** and a remove action for local groups. |
+| **Members** | For a local group: *Users in this group. Search to add someone, or remove with ×.*, a **User** search with **Add**, and the **Member** and **Email** of each member with a remove button. For a synced group: *Members are synced from your identity provider.* |
 | **Roles** | *Roles granted to every member of this group.* Choose **Scope** (**Platform** or **Workspace**) and **Role**, then **Add**. |
 
 When a group holds a role, every member gets it. In the platform a role held through a group works as expected. In the query engine, however, a group name never reaches Trino or StarRocks: engines count only roles a user holds directly, which the **Applied on engines** column of [People & groups](../../data-governance/people-and-groups/index.md) shows as *egret only — not applied on engines: held through a group*.

platform/control-plane/access-control/index.md

@@ -28,18 +28,18 @@ Access overview needs the **user:read** permission, which platform admins hold.
 | **USERS** | Total accounts, with how many are active. |
 | **GROUPS** | Total groups, split into *local* and *synced* (from the identity provider). |
 | **ROLES** | Total roles, split into platform and workspace roles. |
-| **PLATFORM ADMINS** | Users holding the `platform_admin` role, and their share of all users (for example *25% of users — review*). |
+| **PLATFORM ADMINS** | Users holding the `platform_admin` role, and their share of all users (for example *15% of users — review*). |
 
 ### Needs attention
 
 Findings about the way access is set up. Each has a title, a sentence and a **Review** button. Examples on the demo instance:
 
-- **5 roles have no assignees**: *They grant nothing until assigned to a user or group.*
-- **1 platform admins · 25% of users**: *Review who holds full-platform access and trim if it's too broad.*
+- **6 roles have no assignees**: *They grant nothing until assigned to a user or group.* Roles that are only used as workspace roles count here.
+- **2 platform admins · 15% of users**: *Review who holds full-platform access and trim if it's too broad.*
 
 ### Recent changes
 
-The latest audit entries with the action, resource, the actor, and the time. **View audit log** opens the full [Audit log](../audit-log.md).
+The latest audit entries with the action (for example `perm_grant:create`), the resource type, the actor and the time. The actor is shown as a short user id (`by 8a66d837`), not a name. **View audit log** opens the full [Audit log](../audit-log.md).
 
 ### How access works
 

platform/control-plane/access-control/roles.md

@@ -33,7 +33,7 @@ A strip counts **roles**, **platform** and **workspace**. **Scope** filters **Al
 | **Permissions** | How many permissions the role grants, including inherited ones. |
 | **Assignees** | How many users or groups hold it. |
 
-![The tree view groups roles by scope](/img/platform/admin/cp-roles-tree.png)
+![The tree view groups roles by scope and shows inheritance](/img/platform/admin/cp-roles-tree.png)
 
 ## Create a custom role
 
@@ -50,7 +50,7 @@ The new role has no permissions. Open it to add some.
 
 Select a role to open its page. The header says *Workspace role · 8 permissions · 0 assignees* and offers **Delete role**. A role with assignees or child roles shows who holds it; with none it says *No assignees or inheriting roles.*
 
-![A custom workspace role inheriting from ws_viewer with two direct permissions](/img/platform/admin/cp-role-detail.png)
+![The custom workspace role finance_reporter: inherits from ws_viewer and adds two permissions](/img/platform/admin/cp-role-detail.png)
 
 ### Details
 

platform/control-plane/access-control/users.md

@@ -27,6 +27,8 @@ A summary strip counts **users**, **active** and **disabled**. Two filters narro
 | **Roles** | Platform roles the user holds, or a dash. |
 | **Groups** | How many groups the user belongs to. |
 
+The **⋯** menu on a row offers **View access** (the [Access Explorer](./access-explorer.md) for that person), **Assign roles**, **Edit**, **Impersonate** and **Delete**.
+
 ## Create a local account
 
 Use this for break-glass accounts and for installations without SSO.
@@ -45,13 +47,13 @@ Prefer SSO for people. A local account has its own password and does not follow
 
 **Bulk select** adds checkboxes. After you tick users, a bar shows *N selected* with **Disable**, **Enable**, **Assign role…** and **Clear**. **Done** leaves bulk mode.
 
-![Bulk select with one user ticked](/img/platform/admin/cp-users-bulk.png)
+![Bulk select with two users ticked and the actions bar](/img/platform/admin/cp-users-bulk.png)
 
 ## The user page
 
-Select a user to open their page. The header shows the avatar, name, status, provider and email, with **Disable** (or **Enable**) and **Delete**.
+Select a user to open their page. The header shows the avatar, name, status, provider and email, with **Disable** (or **Enable**) and **Delete**. A local account also has **Reset password**: *Set a new password for this local account. Their existing sessions are signed out immediately.*
 
-![A user page with details, roles and groups](/img/platform/admin/cp-user-detail.png)
+![The page of Farid Haddad: details, two platform roles and one group](/img/platform/admin/cp-user-detail.png)
 
 ### Details
 
@@ -73,7 +75,7 @@ The table lists **Role** and **Scope** with a remove button. With none it reads
 
 ## Disable and delete
 
-**Disable** blocks sign-in without removing anything; the status becomes **disabled** and **Enable** reverses it. **Delete** removes the account. Prefer disabling: grants and shares that name a deleted user become unmatched names (see [People & groups](../../data-governance/people-and-groups/index.md)).
+**Disable** blocks sign-in without removing anything and signs the user out; it applies at once, without a confirmation. The status becomes **disabled** and **Enable** reverses it. **Delete** asks *Delete "\<email\>"?* (*This user, their sessions, group memberships, and role grants will be permanently removed. This cannot be undone.*) and needs you to type `delete`. Prefer disabling: grants and shares that name a deleted user become unmatched names (see [People & groups](../../data-governance/people-and-groups/index.md)).
 
 ## Limits and known issues
 

platform/control-plane/audit-log.md

@@ -30,7 +30,7 @@ Every page loads 100 rows. **Load more** fetches the next 100 using a keyset cur
 | **Decision** | An authorization check: the actor asked to do something and the policy engine answered. | **allow** or **deny**, with the grants that decided. | `secret:read` on `platform`, **allow**, `grant-0` |
 | **Mutation** | A change that was made. | A dash. | `member:add`, `object_grant:put`, `perm_rule:create`, `tag:assign` |
 
-Decisions are recorded for the platform's role-based checks. Governance changes also appear on the Governance overview's **Recent changes**; the audit log keeps the raw entries.
+Decisions are recorded for the platform's role-based checks. Impersonation is recorded as the mutations `impersonation.start` (with the reason) and `impersonation.end`, with the admin as the actor; the decisions made while impersonating are recorded under the impersonated user, with nothing that names the admin. Governance changes also appear on the Governance overview's **Recent changes**; the audit log keeps the raw entries.
 
 ## Filter the log