docs(self-hosting): fix errors found verifying the correction pass

A second round of verification checked every added and removed line against
source. It found errors the first pass introduced, which matter more than the
ones it fixed — a wrong new claim is worse than the stale one it replaced.

Corrections to the corrections:

- The GCS bucket table was inverted. Every GCS context falls back to
  GCS_BUCKET_NAME; the rewrite claimed none did. The pre-existing text was
  right and was replaced with a falsehood.
- S3 and Azure each have three fallback exceptions, not one: og-images and
  workspace-logos fall back to the general bucket, and execution-files falls
  back to a literal.
- The proxy table had four wrong rows. Azure OpenAI, Azure Anthropic and vLLM
  are pinned only when the endpoint is user-supplied, so an operator-configured
  endpoint does proxy. Azure Blob and GCS honor the proxy variables; S3 and
  Bedrock do not. SES is the AWS SDK over HTTPS, not raw TCP. Adds the on-prem
  hazard that matters most here: Ollama, LiteLLM and vLLM are dialed over the
  default fetch, so NO_PROXY is required.
- The CloudWatch warning described a bill that cannot happen — every hosted-key
  metric call site is gated on the deployment being Sim Cloud.
- networkPolicy.egressExceptCidrs: [] keeps the metadata defaults rather than
  removing them, since Helm's `default` treats an empty list as unset. Verified
  by rendering the chart. The security guidance said the opposite.
- The migrator retries far more than two error classes, so a database that is
  simply down backs off rather than failing immediately.
- /api/v1/audit-logs authenticates with an API key, not a session, and the
  Enterprise-plan requirement does not apply self-hosted — the exact deployment
  the new paragraph addressed.
- The local upload path is /app/apps/sim/uploads: the standalone server chdirs
  into its own directory.
- The update feed answers 200, not 302. KB_OPENAI_MODEL_NAME is optional.
  OCR_PROVIDER inference is current behavior, not a legacy path.

Restores six things the cleanup dropped that existed nowhere else: version-skip
guidance, the workspace and last-member rejection rules, the gemma3:4b starter
model, kubectl top for OOMKill diagnosis, the grandfathered-workspace case, and
an explicit note that Compose telemetry is on by default.

Also resolves contradictions only visible across pages: the sandbox
prerequisites disagreed on three pages, and authentication.mdx kept a settings
path the enterprise pages had corrected.

The image inventory drops chartVersion. It made every chart-version bump fail a
check whose message says an image changed, and appVersion already pins the tags.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015BwsJTEQRzWJaY4BRCkPZt

Author: waleedlatif1

apps/docs/content/docs/platform/enterprise/access-control.mdx

@@ -13,7 +13,7 @@ Access Control lets organization admins define permission groups that restrict w
 
 ## How it works
 
-Access control is built around **permission groups**. Each group belongs to a specific organization and has a name, an optional description, a **workspace scope**, an optional **member** list, and a configuration that defines what its members can and cannot do. The organization's single **default group** is org-wide; every other group targets a **specific set of workspaces**. A non-default group with **no members** governs **all members** of its workspaces (including external members); adding members narrows it to only those people. Personal workspaces that do not belong to an organization have no permission groups.
+Access control is built around **permission groups**. Each group belongs to a specific organization and has a name, an optional description, a **workspace scope**, an optional **member** list, and a configuration that defines what its members can and cannot do. The organization's single **default group** is org-wide; every other group targets a **specific set of workspaces**. A non-default group with **no members** governs **all members** of its workspaces (including external members); adding members narrows it to only those people. Personal or grandfathered workspaces that do not belong to an organization have no permission groups.
 
 Sim resolves the governing group for a user in a workspace deterministically:
 
@@ -85,7 +85,7 @@ Expand an integration block to reach its **tool denylist**. Clearing individual
 
 Controls the modules, actions, and credentials available to group members. Every row refuses at the API, not only in the UI — clearing a box revokes the access, it does not merely hide a tab.
 
-<Image src="/static/enterprise/access-control-platform.png" alt="Platform tab showing feature toggles grouped by category: Modules, Knowledge Base, Tables, Files, Deployment, Tools, Logs, Collaboration, and Credentials & Access" width={900} height={566} />
+<Image src="/static/enterprise/access-control-platform.png" alt="Platform tab showing feature toggles grouped by category" width={900} height={566} />
 
 **Modules**
 
@@ -182,6 +182,8 @@ A workspace-scoped group applies to **all members of its workspaces by default**
 
 A user is governed by one group per workspace, so adding a user is rejected when it would conflict with another of their groups on a shared workspace (skipped rather than added in bulk). The default group ignores members entirely — it always governs everyone not covered by a workspace group.
 
+A workspace also has at most one all-members group. Adding a workspace to a group, or removing a group's last member, is rejected when doing so would violate that — memberships and scopes are never silently moved.
+
 Manage which workspaces a group governs from the **Workspaces** list on the same **General** tab. A non-default group is created targeting at least one workspace, but you can later remove all of them — a group with no workspaces simply governs nothing until you add one back.
 
 External workspace members (people who have access to a workspace but belong to a different organization) can't be added as named members, but a workspace-scoped group with no members — and the organization default group — still governs them.
@@ -212,7 +214,7 @@ When a user opens Chat, their permission group is read before any block or tool
 <FAQ items={[
   {
     question: "Who can create and manage permission groups?",
-    answer: "Any organization owner or admin on an Enterprise-entitled organization can create, edit, and delete permission groups. The organization must be on the Enterprise plan."
+    answer: "Any organization owner or admin on an Enterprise-entitled organization can create, edit, and delete permission groups. On Sim Cloud that means the organization must be on the Enterprise plan; self-hosted deployments use environment variables instead of the plan check."
   },
   {
     question: "What happens to a workflow that was built before a block was restricted?",

apps/docs/content/docs/platform/enterprise/audit-logs.mdx

@@ -151,11 +151,11 @@ NEXT_PUBLIC_AUDIT_LOGS_ENABLED=true
 
 Once enabled, audit logs are viewable in **Settings → Organization → Audit logs** and accessible via the API.
 
-`GET /api/v1/audit-logs` requires a session and an organization on an Enterprise plan, so it is unreachable on a deployment that has no organization yet. The admin-key equivalent has neither requirement:
+`GET /api/v1/audit-logs` authenticates with an `x-api-key` whose owner is an admin or owner of an organization, so it is unreachable on a deployment where nobody belongs to one yet. On Sim Cloud it additionally requires an active Enterprise subscription; self-hosted, `AUDIT_LOGS_ENABLED` takes that role. The admin-key equivalent needs neither an organization nor a plan:
 
 ```http
 GET /api/v1/admin/audit-logs
 x-admin-key: <admin-api-key>
 ```
 
-It accepts the same filters as the organization endpoint plus `limit` (max 250) and `offset`, and returns entries across the whole deployment rather than one organization. `GET /api/v1/admin/audit-logs/<id>` returns a single entry. Set `ADMIN_API_KEY` to use it — see the [self-hosted enterprise guide](/platform/enterprise/self-hosted).
+It accepts the same filters plus `actorEmail`, drops `includeDeparted`, and paginates with `limit` (max 250) and `offset` instead of the organization endpoint's `limit` (max 100) and `cursor`. It returns entries across the whole deployment rather than one organization. `GET /api/v1/admin/audit-logs/<id>` returns a single entry. Set `ADMIN_API_KEY` to use it — see the [self-hosted enterprise guide](/platform/enterprise/self-hosted).

apps/docs/content/docs/platform/enterprise/custom-blocks.mdx

@@ -131,7 +131,7 @@ Open a block from **Settings → Organization → Custom blocks** to edit or del
   },
   {
     question: "Can consumers see the workflow behind a block?",
-    answer: "No. A custom block only exposes the inputs it needs and the outputs you chose to share. The source workflow, its steps, and its intermediate values are never visible, and consumers don't need any access to it."
+    answer: "A custom block only exposes the inputs it needs and the outputs you chose to share, and consumers don't need any access to the source workflow. Its steps and intermediate values stay hidden unless you enable Trace runs in consumer logs, which surfaces them in the consumer's run trace."
   },
   {
     question: "Can I change which workflow a block points to?",

apps/docs/content/docs/platform/enterprise/data-drains.mdx

@@ -4,6 +4,7 @@ description: Continuously export workflow logs, audit logs, and Chat data to you
 ---
 
 import { FAQ } from '@/components/ui/faq'
+import { Image } from '@/components/ui/image'
 
 Data Drains let organization owners and admins on Enterprise plans continuously export Sim data to a destination they control — a customer-owned S3 bucket, Google Cloud Storage bucket, Azure Blob container, BigQuery table, Snowflake table, Datadog logs intake, or an HTTPS webhook. A drain runs on a schedule, picks up only new rows since its last successful run, and writes them to the destination. Viewing drain configuration and run history is restricted to owners and admins as well, since destinations expose internal bucket names, table identifiers, and webhook URLs.
 
@@ -15,9 +16,9 @@ Drains are independent of [Data Retention](/platform/enterprise/data-retention)
 
 Go to **Settings → Organization → Data drains** in your workspace, then click **New drain**.
 
-![Data Drains settings page showing two configured drains — one exporting workflow logs to Amazon S3 daily, another exporting Copilot chats to an HTTPS webhook hourly](/static/enterprise/data-drains-list.png)
+<Image src="/static/enterprise/data-drains-list.png" alt="Data Drains settings page showing two configured drains — one exporting workflow logs to Amazon S3 daily, another exporting Chat conversations to an HTTPS webhook hourly" width={900} height={477} />
 
-![New data drain dialog with fields for name, source, cadence, destination, and S3 credentials](/static/enterprise/data-drains-new.png)
+<Image src="/static/enterprise/data-drains-new.png" alt="New data drain dialog with fields for name, source, cadence, destination, and S3 credentials" width={900} height={566} />
 
 Each drain has four pieces:
 
@@ -259,4 +260,4 @@ curl -H "Authorization: Bearer $CRON_SECRET" \
   https://sim.example.com/api/cron/run-data-drains
 ```
 
-Each due drain is then fanned out as a `run-data-drain` background job, so the deployment also needs `TRIGGER_DEV_ENABLED` with a configured Trigger.dev project, or the local job backend. See [background jobs](/platform/self-hosting/background-jobs).
+Each due drain is then fanned out as a `run-data-drain` background job, so the deployment also needs `TRIGGER_DEV_ENABLED` with a configured Trigger.dev project, or the default database-backed job queue, which both deployments use out of the box. See [background jobs](/platform/self-hosting/background-jobs).

apps/docs/content/docs/platform/enterprise/data-retention.mdx

@@ -102,7 +102,7 @@ For each stage, choose the **entity types** to redact from the searchable grid.
 - **United Kingdom** — NHS number, National Insurance number
 - **Other regions** — Spanish (NIF, NIE), Italian (fiscal code, driver's licence, VAT code, passport, identity card), Polish (PESEL), Singaporean (NRIC/FIN, UEN), Australian (ABN, ACN, TFN, Medicare), Indian (PAN, Aadhaar, vehicle registration, voter ID, passport), and Finnish (personal identity code) identifiers
 
-The **Block outputs** stage is restricted to regex- and checksum-based recognizers, so it can run in-flight over large payloads without a performance penalty. Types that need name-model detection — person name, location, date or time — are not offered for that stage.
+The **Block outputs** stage is restricted to regex- and checksum-based recognizers, so it can run in-flight over large payloads without a performance penalty. Types that need name-model detection — person name, location, date or time, and nationality/religious/political group — are not offered for that stage.
 
 Detection is language-aware: pick the **language** whose recognizers should apply. English, Spanish, Italian, Polish, and Finnish are supported, and the grid filters to the identifiers available for the selected language.
 
@@ -205,15 +205,15 @@ curl -H "Authorization: Bearer $CRON_SECRET" \
   https://sim.example.com/api/logs/cleanup
 ```
 
-Each call fans the work out as background jobs, so the deployment also needs `TRIGGER_DEV_ENABLED` with a configured Trigger.dev project, or the local job backend.
+Each call fans the work out as background jobs, so the deployment also needs `TRIGGER_DEV_ENABLED` with a configured Trigger.dev project, or the default database-backed job queue, which both deployments use out of the box.
 
 ### PII redaction
 
 PII redaction runs against a standalone [Presidio](https://microsoft.github.io/presidio/) service. Deploy it (see `apps/pii`) and point Sim at it:
 
 ```bash
 # The Presidio service exposing /analyze and /anonymize
-PII_URL=http://localhost:5001
+PII_URL=http://sim-pii.simstudio.svc.cluster.local:5001
 ```
 
 All PII stages are configurable under **Settings → Organization → Data retention**.

apps/docs/content/docs/platform/enterprise/self-hosted.mdx

@@ -92,7 +92,7 @@ curl -H "Authorization: Bearer $CRON_SECRET" \
   https://sim.example.com/api/logs/cleanup
 ```
 
-Both features also fan work out as background jobs, so the deployment needs `TRIGGER_DEV_ENABLED` with a configured Trigger.dev project, or the local job backend. See [background jobs](/platform/self-hosting/background-jobs).
+Both features also fan work out as background jobs, so the deployment needs `TRIGGER_DEV_ENABLED` with a configured Trigger.dev project, or the default database-backed job queue, which both deployments use out of the box. See [background jobs](/platform/self-hosting/background-jobs).
 
 ## Choose an organization model
 
@@ -233,7 +233,7 @@ curl "https://sim.example.com/api/v1/admin/access-control?organizationId=$ORG_ID
   -H "x-admin-key: $ADMIN_API_KEY"
 ```
 
-The organization-scoped `/api/v1/audit-logs` endpoint documented in the [audit logs guide](/platform/enterprise/audit-logs) requires a session and an organization on an Enterprise plan, so reach for the admin endpoints when neither exists yet.
+The organization-scoped `/api/v1/audit-logs` endpoint documented in the [audit logs guide](/platform/enterprise/audit-logs) needs an API key whose owner is an admin or owner of an organization, so reach for the admin endpoints when no organization exists yet.
 
 Deleting an organization requires echoing its slug, because the delete cascades to members, invitations, and permission groups, and detaches its workspaces:
 

apps/docs/content/docs/platform/enterprise/verified-domains.mdx

@@ -73,4 +73,4 @@ NEXT_PUBLIC_SSO_ENABLED=true
 
 `ENTERPRISE_ENABLED` turns both on together. See the [self-hosted enterprise guide](/platform/enterprise/self-hosted).
 
-Once enabled, verify domains from **Settings → Organization → Single sign-on**, in the **Verified domains** section above the identity provider configuration. The older `/settings/domains` link still resolves — it redirects to the same page.
+Once enabled, verify domains from **Settings → Organization → Single sign-on**, in the **Verified domains** section above the identity provider configuration. The older `/settings/domains` link still resolves to the same page.

apps/docs/content/docs/platform/enterprise/whitelabeling.mdx

@@ -85,7 +85,7 @@ The organization settings have no favicon and no custom-CSS field. Set those ins
   },
   {
     question: "Do members outside my organization see the custom branding?",
-    answer: "No. Custom branding is scoped to your organization. Members see your branding when signed in to your organization's workspace."
+    answer: "Organization white-labeling is scoped to your organization — members see it when signed in to your organization's workspace. Instance-wide branding is different: it needs no organization and applies to the whole deployment, including signed-out pages."
   }
 ]} />
 

apps/docs/content/docs/platform/self-hosting/authentication.mdx

@@ -75,7 +75,7 @@ SSO_ENABLED=true
 NEXT_PUBLIC_SSO_ENABLED=true
 ```
 
-Providers are then registered in the app under **Settings → Enterprise → Single Sign-On**. A provider can be scoped to an organization or registered without one. Most other enterprise features do read their settings from the organization that owns a workspace, so a deployment using them still needs an organization model — set `INSTANCE_ORG_NAME` to place every user in one shared organization, or provision organizations through the Admin API.
+Providers are then registered in the app under **Settings → Organization → SSO**. A provider can be scoped to an organization or registered without one. Most other enterprise features do read their settings from the organization that owns a workspace, so a deployment using them still needs an organization model — set `INSTANCE_ORG_NAME` to place every user in one shared organization, or provision organizations through the Admin API.
 
 See the [SSO guide](/platform/enterprise/sso) for identity-provider setup and the [self-hosted enterprise guide](/platform/enterprise/self-hosted) for the organization patterns.
 

apps/docs/content/docs/platform/self-hosting/desktop.mdx

@@ -29,9 +29,9 @@ Both endpoints cache their GitHub lookups for **5 minutes**, and both respond th
 
 | Status | Meaning |
 |---|---|
-| `302` | Success — redirect to the release asset |
+| `302` | Success on `/download` — a redirect to the release asset. The update feed answers `200` with `text/yaml` instead |
 | `404` | GitHub answered, but this channel has no release |
-| `502` | GitHub was unreachable, or every candidate release lacked valid desktop artifacts |
+| `502` | GitHub could not be read — unreachable, rate-limited, or every candidate release lacked valid desktop artifacts |
 
 The Sim server needs outbound access to `api.github.com` and `github.com` for these to resolve. Unauthenticated GitHub API requests are capped at 60/hour per IP; set `GITHUB_TOKEN` on the Sim server to raise that to 5000/hour.