fix(supply-chain): never attest a moving tag this run did not publish

The resolver added `latest` unconditionally. When create-ghcr-manifests' guard
holds those tags back — it does that when the branch has moved on — they still
point at an older build, so the job would have put this run's signature and
provenance on an image it did not produce. A moving alias is now included only
when it resolves to the index this run published; the per-arch aliases ship in
the same guarded block, so one comparison gates all three.

`digest_of` also aborted the step instead of reporting an absent tag: under
`set -e` a failing inspect inside a command substitution takes the step down
before the caller can skip it. Confirmed against a real registry, then fixed
with an explicit `if !` rather than swallowing the status.

Docs, all verified against source:

- The General tab does not buffer everything: workspace scope, the default
  switch, and member changes apply immediately, so Discard does not undo them.
- Both data-drain screenshots were declared at the wrong aspect ratio when I
  converted them to <Image>; they rendered distorted.
- LM Studio needs VLLM_API_KEY when its API authentication is on.
- The rollback snippet hardcoded a version that does not exist.
- Docker Compose schedules the drain endpoint too, so the table implied Compose
  operators had to add their own.
- Generating CRON_SECRET in a shell configures neither the app nor the caller.
- SANDBOXES_ENABLED is required beyond the provider and Function base on a
  billing-free self-host, and Pi runs on its own image and fails closed without
  E2B_PI_TEMPLATE_ID or DAYTONA_PI_SNAPSHOT_ID.

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

Author: waleedlatif1

.github/workflows/ci.yml

@@ -664,21 +664,51 @@ jobs:
           set -euo pipefail
 
           IMAGES="simstudio migrations realtime pii cron"
-          TAGS="${SHA} ${SHA}-amd64 ${SHA}-arm64 latest latest-amd64 latest-arm64"
-          if [ "${IS_RELEASE}" = "true" ]; then
-            TAGS="${TAGS} ${VERSION} ${VERSION}-amd64 ${VERSION}-arm64"
-          fi
+
+          # Prints the digest, or nothing when the tag is not published. The
+          # explicit `if !` matters: under `set -e` a failing inspect inside a
+          # command substitution aborts the step before the caller can treat an
+          # absent tag as "skip".
+          digest_of() {
+            local raw
+            if ! raw="$(docker buildx imagetools inspect "$1" --format '{{json .Manifest}}' 2>/dev/null)"; then
+              return 0
+            fi
+            printf '%s' "$raw" | jq -r '.digest // empty'
+          }
 
           : > /tmp/subjects.jsonl
           for name in $IMAGES; do
             image="ghcr.io/simstudioai/${name}"
+
+            # The sha tags are this run's own output and always exist.
+            sha_index="$(digest_of "${image}:${SHA}")"
+            if [ -z "$sha_index" ]; then
+              echo "::error::No index published for ${image}:${SHA}"
+              exit 1
+            fi
+            tags="${SHA} ${SHA}-amd64 ${SHA}-arm64"
+
+            # A moving alias is only ours if it resolves to the index this run
+            # published. create-ghcr-manifests holds the latest tags back when
+            # its monotonic guard sees a newer commit, and they then still point
+            # at an older build — attesting those would put this run's signature
+            # and provenance on an image it did not produce. The per-arch
+            # aliases are published in the same guarded block as `latest`, so
+            # that one comparison gates all three.
+            if [ "$(digest_of "${image}:latest")" = "$sha_index" ]; then
+              tags="${tags} latest latest-amd64 latest-arm64"
+            else
+              echo "Skipping latest tags for ${image}: they do not point at this run's index."
+            fi
+
+            if [ "${IS_RELEASE}" = "true" ] && [ "$(digest_of "${image}:${VERSION}")" = "$sha_index" ]; then
+              tags="${tags} ${VERSION} ${VERSION}-amd64 ${VERSION}-arm64"
+            fi
+
             seen=""
-            for tag in $TAGS; do
-              # A tag that this run did not publish (no release, or the latest
-              # guard held it back) is expected to be missing — skip it rather
-              # than fail the run.
-              digest="$(docker buildx imagetools inspect "${image}:${tag}" \
-                --format '{{json .Manifest}}' 2>/dev/null | jq -r '.digest // empty')"
+            for tag in $tags; do
+              digest="$(digest_of "${image}:${tag}")"
               [ -n "$digest" ] || continue
               case " $seen " in *" $digest "*) continue ;; esac
               seen="$seen $digest"

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

@@ -45,7 +45,7 @@ Click **+ Create** and enter a name (required) and optional description. A group
 
 ### 3. Configure permissions
 
-Click **Details** on a group to open its configuration. It has four tabs — **General**, **Model Providers**, **Blocks**, and **Platform**. Changes are buffered until you save.
+Click **Details** on a group to open its configuration. It has four tabs — **General**, **Model Providers**, **Blocks**, and **Platform**. Name, description, and the permission settings are buffered until you save; the workspace scope, the default-group switch, and member changes are applied immediately, so **Discard** does not undo them.
 
 Throughout the editor, a **checked** box means allowed. Clearing a checkbox is what applies a restriction.
 

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

@@ -16,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**.
 
-<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} />
+<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={885} />
 
-<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} />
+<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={491} />
 
 Each drain has four pieces:
 

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

@@ -72,15 +72,17 @@ See [Sandboxes](/platform/self-hosting/sandboxes) for the provider credentials,
 Two enterprise features do their work from a cron-driven HTTP endpoint rather than from the app process. All four endpoints authenticate with a bearer token equal to `CRON_SECRET`, and both return `401` when `CRON_SECRET` is unset:
 
 ```bash
-CRON_SECRET=$(openssl rand -hex 32)
+openssl rand -hex 32
 ```
 
-| Feature | Endpoint | Suggested schedule | Scheduled by the Helm chart |
-|---------|----------|--------------------|-----------------------------|
-| Data drains | `GET /api/cron/run-data-drains` | Hourly | Yes |
-| Retention — logs | `GET /api/logs/cleanup` | Daily | **No** |
-| Retention — soft deletes | `GET /api/cron/cleanup-soft-deletes` | Daily | **No** |
-| Retention — Chat tasks | `GET /api/cron/cleanup-tasks` | Daily | **No** |
+Persist that value as `CRON_SECRET` on the app **and** on whatever calls these endpoints. Generating it in a shell configures neither, and a mismatch returns `401`, so the work silently never runs.
+
+| Feature | Endpoint | Suggested schedule | Scheduled for you |
+|---------|----------|--------------------|-------------------|
+| Data drains | `GET /api/cron/run-data-drains` | Hourly | Yes — Helm and Docker Compose both call it |
+| Retention — logs | `GET /api/logs/cleanup` | Daily | **No** — schedule it yourself |
+| Retention — soft deletes | `GET /api/cron/cleanup-soft-deletes` | Daily | **No** — schedule it yourself |
+| Retention — Chat tasks | `GET /api/cron/cleanup-tasks` | Daily | **No** — schedule it yourself |
 
 <Callout type="warn">
   The Helm chart schedules the data-drain dispatcher but **not** the three retention cleanup endpoints. Setting `DATA_RETENTION_ENABLED=true` on the chart alone deletes nothing — the windows are evaluated only when one of those endpoints is called. Add them to `cronjobs.jobs` yourself, or drive them from an external scheduler.

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

@@ -131,7 +131,10 @@ Workflows can execute user-authored JavaScript and Python. Know which sandbox yo
 | **Daytona** | `SANDBOX_PROVIDER=daytona`, `DAYTONA_API_KEY`, `DAYTONA_FUNCTION_SNAPSHOT_ID` | Remote sandbox per execution. |
 
 Python, Shell, JavaScript with external imports, and tooling-dependent blocks
-require a remote sandbox provider. JavaScript without `import` or `require`
+require a remote sandbox provider. On a billing-free self-host the provider and
+Function base are not sufficient on their own: `SANDBOXES_ENABLED` grants the
+server-side entitlement, and without it Shell and the Sandboxes settings stay
+hidden even when the provider is configured correctly. JavaScript without `import` or `require`
 continues to run in the in-process isolate when no remote provider is configured.
 
 <Callout type="warn">
@@ -149,7 +152,7 @@ Two browser-side variables project server state into the UI, and neither is deri
 | Variable | Effect when unset |
 |---|---|
 | `NEXT_PUBLIC_SANDBOXES_ENABLED` | The Function block's Shell language, its Sandbox picker, and **Settings → Sandboxes** stay hidden, even with a working provider. Python stays selectable and fails at execution |
-| `NEXT_PUBLIC_E2B_ENABLED` | The E2B-backed Pi block modes stay hidden; `sim-setup doctor` reports it as a mismatch against `E2B_ENABLED` |
+| `NEXT_PUBLIC_E2B_ENABLED` | The E2B-backed Pi block modes stay hidden; `sim-setup doctor` reports it as a mismatch against `E2B_ENABLED`. Revealing them is not enough to make them run — Pi executes on its own image, pinned with `E2B_PI_TEMPLATE_ID` or `DAYTONA_PI_SNAPSHOT_ID`, and fails closed without it |
 
 Set the public values only **after** the server-side configuration above is complete — they are assertions about readiness, not switches, and the server-side check has its own conditions beyond them. See [Sandboxes](/platform/self-hosting/sandboxes) for the base-image build and promotion procedure. `npx sim-setup doctor` reports a mismatch in either direction.
 

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

@@ -59,7 +59,7 @@ Two things this does not cover:
 
 Sim identifies dynamically discovered LM Studio and vLLM models by their `vllm/` prefix. If the endpoint is unavailable and you manually enter the raw LM Studio model identifier, Sim treats that unknown identifier as an Ollama model.
 
-1. Set `VLLM_BASE_URL`. No Compose file sets it for you — `docker-compose.ollama.yml` only sets `OLLAMA_URL` — so add it to the `simstudio` service's `environment:` block (or to `.env` and interpolate it), then recreate the service and confirm it landed:
+1. Set `VLLM_BASE_URL`, and `VLLM_API_KEY` too if you enabled LM Studio's API authentication — without the key, discovery requests omit the bearer token and fail. No Compose file sets either for you — `docker-compose.ollama.yml` only sets `OLLAMA_URL` — so add them to the `simstudio` service's `environment:` block (or to `.env` and interpolate them), then recreate the service and confirm it landed:
 
    ```bash
    docker compose -f docker-compose.ollama.yml up -d --force-recreate simstudio

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

@@ -250,8 +250,9 @@ helm rollback sim -n simstudio
 ```
 
 ```bash
-# Docker Compose — edit .env so the pin persists, then restart
-echo "SIM_VERSION=v1.2.2" >> .env
+# Docker Compose — edit .env so the pin persists, then restart.
+# Substitute the previous release tag from the releases page.
+echo "SIM_VERSION=<previous-release-tag>" >> .env
 docker compose -f docker-compose.prod.yml up -d
 ```