chore(sandbox): drop the ts/go daemon switch, Go is the only implementation

[pedrofrxncx]

Summary

Teardown #1 of the Go rollout scaffolding, on top of #5568 (now merged — Go is the default).

Once Go is the only daemon, every lever that let a sandbox be TS is dead weight. Removed end to end:

Removed	Was
apps/api/src/sandbox/resolve-daemon-impl.ts (+test)	prop → org flag → default resolution
sandbox_go_daemon in OrgFlagsSchema	per-org opt-out
SANDBOX_START's daemonImpl input	per-sandbox pin
SandboxDaemonImpl / sandboxDaemonImplSchema / EnsureOptions.daemonImpl	the type itself
resolveClaimTemplate + claim-template.test.ts	which template a claim names
readClaimDaemonImpl, LABEL_KEYS.daemonImpl	the studio.decocms.com/daemon-impl label
STUDIO_SANDBOX_GO_TEMPLATE_NAME / goSandboxTemplateName	the global kill switch
chart daemonImpl, goTemplate.*, image.goRepository	the twin-template machinery

image.repository now points at studio-sandbox-go and the chart renders one SandboxTemplate and one SandboxWarmPool again — back to the pre-canary shape, with the other binary.

Two things reviewers should push on

1. The daemon_impl metric attribute is gone. It was the Go-vs-TS comparison dimension on every sandbox metric (tenantAttrs), plus the matching pod label. With one implementation it's a constant, but any Grafana panel filtering or splitting on daemon_impl breaks on deploy — those filters need removing. I did not touch dashboards; flagging rather than silently leaving a constant dimension.

2. Deploy order is load-bearing. This deletes studio-sandbox-<env>-go and flips the surviving template's image TS→Go (which rolls the warm pool). The API must ship first — it's the side that stops naming the -go template. Sync the chart before the API and in-flight claims reference a template that no longer exists. Chart 0.9.67 → 0.10.0, with the hazard written into the Chart.yaml upgrade note.

The matching CD change (drop goTemplate, collapse back to one KEDA ScaledObject, drop STUDIO_SANDBOX_GO_TEMPLATE_NAME) is a follow-up in decocms/deco-apps-cd and must sync after this deploys.

Testing

• bun test apps/api/src/sandbox apps/api/src/tools/sandbox packages/sandbox/server — 267 pass. Deleted the three SANDBOX_START daemon-impl cases and the whole claim-template.test.ts (its only subject was the removed function); dropped the now-unused orgFlags knob from the SANDBOX_START test harness.
• helm template + helm lint on sandbox-env: one SandboxTemplate, one SandboxWarmPool, image studio-sandbox-go, 0 failures.
• bun run --cwd <ws> check clean for apps/api, packages/sandbox, packages/shared. knip clean — no orphans left behind.
• Pre-existing and NOT from this branch: bun run check:readmes fails on a missing apps/mesh/package.json (fails on main too), and apps/web has ~20 react-resizable-panels type errors from dependency drift.

Next in the series

Separate PRs, each revertable on its own: remove the desktop link feature, then delete packages/sandbox/daemon (extracting the org-fs sidecar and the Go conformance suite first).

---

Summary by cubic

Make Go the only sandbox daemon and remove the TS/Go switch across Studio and the Helm chart. The chart now renders one template and warm pool using studio-sandbox-go, and metrics no longer include daemon_impl.

• Refactors

  • Removed daemonImpl from SANDBOX_START, the sandbox_go_daemon org flag, and the claim label/resolve logic.
  • Dropped SandboxDaemonImpl types and related tests.
  • Deleted dual-template machinery; image.repository points to studio-sandbox-go.
  • Removed daemon_impl metric/label from runner and tenant attrs.

• Migration

  • Update Grafana dashboards: remove any filters/splits on daemon_impl.
  • Deploy order: ship API first (it stops naming the -go template), then sync deploy/helm/sandbox-env 0.10.0; this flips the default image and deletes studio-sandbox-<env>-go.
  • Follow up in decocms/deco-apps-cd: collapse back to one KEDA ScaledObject and drop STUDIO_SANDBOX_GO_TEMPLATE_NAME after this deploy.

^{Written for commit 0d051ef. Summary will update on new commits.}

[cubic-dev-ai]

2 issues found across 18 files

_{You’re at about 90% of the monthly reviewed-line limit. You may want to disable incremental reviews to conserve quota. Reviews will continue until that limit is exceeded. If you need help avoiding interruptions, please contact contact@cubic.dev.}

Prompt for AI agents (unresolved issues)

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="deploy/helm/sandbox-env/values.yaml">

<violation number="1" location="deploy/helm/sandbox-env/values.yaml:44">
P2: The documented kind deployment still runs the TS daemon because its overlay and reload script explicitly select the bare `studio-sandbox` image, so this Go-only default is not applied to local validation. Updating the kind overlay/build command to use `studio-sandbox-go` and the Dockerfile's `go` target would keep the supported environment consistent.</violation>

<violation number="2" location="deploy/helm/sandbox-env/values.yaml:44">
P1: A chart release can now point at a missing Go image because the sandbox image release gate checks only the legacy TS repository before skipping both builds. Checking the Go manifest as well, or building/publishing the Go image independently when its tag is missing, would prevent production pods from becoming unpullable.</violation>
</file>

<sub>Reply with feedback, questions, or to request a fix.

Re-trigger cubic</sub>

[cubic-dev-ai]

P1: A chart release can now point at a missing Go image because the sandbox image release gate checks only the legacy TS repository before skipping both builds. Checking the Go manifest as well, or building/publishing the Go image independently when its tag is missing, would prevent production pods from becoming unpullable.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At deploy/helm/sandbox-env/values.yaml, line 44:

<comment>A chart release can now point at a missing Go image because the sandbox image release gate checks only the legacy TS repository before skipping both builds. Checking the Go manifest as well, or building/publishing the Go image independently when its tag is missing, would prevent production pods from becoming unpullable.</comment>

<file context>
@@ -39,10 +39,9 @@ envName: ""
-  goRepository: ghcr.io/decocms/studio/studio-sandbox-go
+  # The Go sandbox daemon. The daemon implementation IS the image — there is no
+  # runtime switch, so a pod cannot disagree with the template that created it.
+  repository: ghcr.io/decocms/studio/studio-sandbox-go
   # Pinned to a specific version so chart upgrades pull a matching image
   # instead of silently moving with `:latest`. Bump in lockstep with
</file context>

[cubic-dev-ai]

P2: The documented kind deployment still runs the TS daemon because its overlay and reload script explicitly select the bare studio-sandbox image, so this Go-only default is not applied to local validation. Updating the kind overlay/build command to use studio-sandbox-go and the Dockerfile's go target would keep the supported environment consistent.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At deploy/helm/sandbox-env/values.yaml, line 44:

<comment>The documented kind deployment still runs the TS daemon because its overlay and reload script explicitly select the bare `studio-sandbox` image, so this Go-only default is not applied to local validation. Updating the kind overlay/build command to use `studio-sandbox-go` and the Dockerfile's `go` target would keep the supported environment consistent.</comment>

<file context>
@@ -39,10 +39,9 @@ envName: ""
-  goRepository: ghcr.io/decocms/studio/studio-sandbox-go
+  # The Go sandbox daemon. The daemon implementation IS the image — there is no
+  # runtime switch, so a pod cannot disagree with the template that created it.
+  repository: ghcr.io/decocms/studio/studio-sandbox-go
   # Pinned to a specific version so chart upgrades pull a matching image
   # instead of silently moving with `:latest`. Bump in lockstep with
</file context>