PR #1622 shipped the sandbox-controller binary + chart, and PR #1618
shipped pty-server + mcp-server scaffolds, but neither came with CI
build workflows — meaning the chart's image.repository points at a
GHCR package that no workflow ever publishes (ImagePullBackOff on
every install). Per docs/INVIOLABLE-PRINCIPLES.md #4a every runtime
image MUST be produced by a GitHub Actions workflow from a committed
git SHA; this PR closes that gap.
Three new workflows, all event-driven (push paths-filter + PR +
workflow_dispatch, no cron):
- build-sandbox-controller.yaml — mirrors build-application-controller
(shared core/controllers go.mod, go vet + race tests, Buildx push,
cosign keyless sign, SBOM attest, auto-bump platform/sandbox/chart/
values.yaml image.tag back to main so the next install picks up the
SHA-pinned image without operator action).
- build-sandbox-pty-server.yaml — separate go module under
products/sandbox/pty-server (own go.mod/go.sum), Dockerfile uses
COPY . . so build context is the server directory. Same Buildx +
cosign + SBOM flow as the controller. No values.yaml bump yet:
Wave-2 wiring of the StatefulSet template will land in a follow-up.
- build-sandbox-mcp-server.yaml — stdlib-only stdio MCP sidecar
(no go.sum yet), same shape as pty-server.
Per `feedback_no_mvp_no_workarounds.md` rule 1 (target-state, never
"manual follow-up bump") the controller workflow auto-bumps the chart
values.yaml so a Sovereign overlay flipping `enabled: true` Just Works.
Per the user's hard rule for this PR, no Chart.yaml bump and no
blueprint-release dispatch — the Sandbox chart's publication cadence
is gated by Wave-2 readiness, not per-image builds.
Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
1b0e86cb1a