Cloud Agent Next - Add Guarded PR Staging Deployments

[eshurakov]

Summary

• Add an isolated Cloud Agent Next staging environment that shares production-backed authentication and integrations while separating containers, Durable Objects, queues, and session logs.
• Add a guarded manual workflow that tests and deploys an authorized same-repository PR merge commit, validates the exact staging configuration, and runs an authenticated smoke check.
• Keep staging credentials as direct Worker secrets configured in Cloudflare rather than migrating them to Secrets Store.

Verification

• Ran a local Wrangler dry-run for env.staging and confirmed the expected bindings and container builds without deploying remotely.

Visual Changes

N/A

Reviewer Notes

• Configure required staging secrets directly on cloud-agent-next-staging in the Cloudflare dashboard before the first deployment.
• The staging Worker intentionally uses production Hyperdrive and shared production services; reviewed PR code can therefore access production-backed data and integrations.

[kilo-code-bot]

Code Review Summary

Status: No Issues Found | Recommendation: Merge

Executive Summary

The PR introduces a well-guarded staging deployment for cloud-agent-next with careful SHA pinning, config allowlist validation, and proper isolation of secrets, queues, and Durable Objects from production.

Files Reviewed (9 files)

• .github/workflows/deploy-cloud-agent-next-staging.yml — new guarded workflow
• services/cloud-agent-next/wrangler.jsonc — staging env block
• services/cloud-agent-next/src/types.ts — INTERNAL_API_SECRET_PROD made optional
• services/cloud-agent-next/src/persistence/types.ts — same optionality update
• services/cloud-agent-next/src/telemetry/report-consumer.ts — staging queue name added
• services/cloud-agent-next/src/server.test.ts — staging queue test
• services/cloud-agent-next/src/staging-config.test.ts — new config invariant tests
• services/cloud-agent-next/src/callbacks/queue-config.test.ts — staging retry budget test
• services/cloud-agent-next/src/kilo/devcontainer.test.ts — refactored container version check
• services/cloud-agent-next/worker-configuration.d.ts — regenerated types with StagingEnv

Security Design Notes

The workflow security model is correct:

• Workflow is workflow_dispatch only and guarded to refs/heads/main at the first step
• PR is validated as same-repository and open before trusting the merge SHA
• The merge SHA is re-checked immediately before wrangler deploy to detect force-pushes between the test and deploy jobs
• The config validation step runs an inline Node.js heredoc (not candidate code) that only reads wrangler.jsonc as data, using a pinned jsonc-parser from a separate TRUSTED_TOOLS_DIR — this correctly avoids executing any PR-contributed JavaScript
• wrangler is pinned to an exact version (4.90.1) in an isolated directory, not resolved from the candidate lockfile
• Staging Durable Objects, queues, and R2 bucket are isolated from production; crons are explicitly cleared to prevent the production report retention job from running on staging
• INTERNAL_API_SECRET_PROD (Secrets Store binding) is correctly made optional — staging uses a plain INTERNAL_API_SECRET Worker secret, which worker-configuration.d.ts confirms is string (non-optional) in StagingEnv

Fix these issues in Kilo Cloud

---

_{Reviewed by claude-4.6-sonnet-20260217 · 3,293,685 tokens}

_{Review guidance: REVIEW.md from base branch main}