[eshurakov]

Summary

• Replace the webhook/scheduled trigger Dedicated Standard selector with provider-grouped sandbox choices using Cloud Agent capacity labels and eligibility.
• Include the new Cloudflare Containers runtime and available instance sizes, with repository-aware availability checked in the UI and server.
• Carry shared allocation keys through API validation, Durable Object persistence, and session preparation; retain existing legacy allocations without silently migrating them.
• Preserve Automatic/default routing, unchanged-edit omission, and explicit clearing. Legacy allocations are not offered for new selections.

Verification

• 120 focused web tests passed across TriggerForm, webhook router, and worker client.
• 154 webhook worker unit tests and 54 worker integration tests passed.
• Web and webhook worker TypeScript checks passed.
• Changed-file lint, formatting, and git diff --check passed.
• Independent review found no blocking issues.

Notes

• Focused web suites use a no-op per-worker database setup because PostgreSQL is unavailable; these suites mock DB access. Normal test environment loading is retained.
• Live browser verification was not run.
• UI follows the Kilo Cloud design overlay and interaction-quality reference, reusing shipped Select primitives and Cloud Agent grouping/formatting helpers. No dedicated sandbox-picker design recipe exists.
• Deploy the webhook ingest worker support before exposing the new web choices. No database migration is needed.

[kilo-code-bot]

Code Review Summary

Status: No Issues Found | Recommendation: Merge

Executive Summary

The full PR (18 files) was re-reviewed because the previously reviewed commit 810bfd7b is no longer an ancestor of HEAD (history was rewritten), and the three earlier findings are confirmed fixed: capability loading/error states now gate the unavailable sandbox UI, the edit capabilities query waits for triggerData, and the Web/Worker legacy-allocation rules share isSandboxAllocationAvailable in worker-utils. No new blocking issues were found in the widened sandbox allocation flow, the Worker persistence/forwarding path, or the form logic.

Assumptions: [INFERENCE] Verification is static; no tests, type checks, or runtime checks were executed in this read-only review. [INFERENCE] End-to-end session execution for vercel-* and cloudflare-containers-* allocations through the webhook ingest prepareSession path was not executed; the PR's own worker integration tests and deployment note ("deploy webhook ingest worker support before exposing new web choices") cover that path. The three previously posted inline findings are outdated on GitHub (line: null) and their fixes were verified in current code, so they are not repeated.

Files Reviewed (18 files)

• apps/web/src/app/(app)/cloud/webhooks/[triggerId]/EditWebhookTriggerContent.tsx
• apps/web/src/app/(app)/cloud/webhooks/new/CreateWebhookTriggerContent.tsx
• apps/web/src/components/webhook-triggers/TriggerForm.tsx
• apps/web/src/components/webhook-triggers/TriggerForm.test.ts
• apps/web/src/lib/webhook-agent/webhook-agent-client.ts
• apps/web/src/lib/webhook-agent/webhook-agent-client.test.ts
• apps/web/src/routers/webhook-triggers-router.ts
• apps/web/src/routers/webhook-triggers-router.schema.test.ts
• packages/worker-utils/src/sandbox-allocation.ts
• packages/worker-utils/src/sandbox-allocation.test.ts
• services/cloud-agent-next/src/sandbox-selection.ts
• services/kilo-mcp/catalog.json (generated)
• services/webhook-agent-ingest/src/dos/TriggerDO.ts
• services/webhook-agent-ingest/src/queue-consumer.ts
• services/webhook-agent-ingest/src/queue-consumer.test.ts
• services/webhook-agent-ingest/src/routes/api.ts
• services/webhook-agent-ingest/src/routes/api.test.ts
• services/webhook-agent-ingest/test/integration/trigger-do.test.ts

Previous Review Summaries (4 snapshots, latest commit 810bfd7)

Current summary above is authoritative. Previous snapshots are kept for context only.

Previous review (commit 810bfd7)

Status: No Issues Found | Recommendation: Merge

Executive Summary

The only change since the previous review is a revert of the one-line BackHandler mock in the mobile to-do model picker mounted test, restoring the file to its prior state; nothing in that test's render path (ModelPickerContent, TodoListSettingsSheet, PickerSheet, selectors, test helpers) imports or calls BackHandler, so the revert introduces no new behavior or coverage gap, and no webhook files changed.

Assumptions: [INFERENCE] Verification is static; no tests or type checks were executed in this read-only review. Whether the reverted commit was accidentally included from another branch is not stated in the PR body, but the revert restores the pre-existing test configuration and touches no production code. Previously reported findings on TriggerForm.tsx, EditWebhookTriggerContent.tsx, and webhook-triggers-router.ts were fixed in 4a177f99bd and their files are unchanged since, so they are not repeated here.

Files Reviewed (1 file)

• apps/mobile/src/components/todos/todo-list-model-picker.mounted.test.tsx

Previous review (commit faca2d0)

Status: No Issues Found | Recommendation: Merge

Executive Summary

The only incremental change is a one-line test-only mock that adds BackHandler to the react-native mock in the to-do list model picker mounted test, matching the existing helper pattern used by other mobile suites; no new correctness, security, or resource-lifetime issues were found.

Assumptions: [INFERENCE] Verification is static; no tests or type checks were executed in this read-only review. The mock returns a fresh { remove } subscription per addEventListener call, which satisfies the NativeEventSubscription shape the components use, and no production code changed. The previously reported findings from commit 4a177f99bd were re-checked and remain resolved, so they are not repeated here.

Files Reviewed (1 file)

• apps/mobile/src/components/todos/todo-list-model-picker.mounted.test.tsx - no issues

Previous review (commit 4a177f9)

Status: No Issues Found | Recommendation: Merge

Executive Summary

The follow-up commit addresses all three prior findings: the sandbox field waits for capabilities instead of treating missing data as unavailable, loading and failure have distinct messages plus a retry action, and web and Worker now share one availability predicate; no new correctness, security, accessibility, or resource-lifetime issues were found in the incremental diff.

Assumptions: [INFERENCE] Verification is static; no tests or type checks were executed in this read-only review. Prior findings were re-checked against HEAD 4a177f99bd and are resolved, so they are not repeated here. hasCapabilitiesError uses React Query isError, which remains true during an in-flight retry until the retry succeeds; the retry button stays enabled in that window, but concurrent refetches are deduplicated by React Query. Edit-mode capability errors surface only after triggerData exists, and personal (no-organization) triggers never issue a Worker capabilities request, so the new error UI cannot appear for them.

Files Reviewed (9 files)

• apps/web/src/app/(app)/cloud/webhooks/[triggerId]/EditWebhookTriggerContent.tsx - no issues (query gated on triggerData, error and retry wired)
• apps/web/src/app/(app)/cloud/webhooks/new/CreateWebhookTriggerContent.tsx - no issues (error and retry wired)
• apps/web/src/components/webhook-triggers/TriggerForm.tsx - no issues (unavailable state requires loaded capabilities; validation fails closed on error; Automatic remains selectable)
• apps/web/src/components/webhook-triggers/TriggerForm.test.ts - no issues (covers loading, refresh, error/retry, unchanged omission, explicit clear, blocked change)
• apps/web/src/routers/webhook-triggers-router.ts - no issues (delegates to the shared predicate after the existing org and enrollment checks)
• apps/web/src/routers/webhook-triggers-router.schema.test.ts - no issues (both legacy allocations covered for create and update)
• packages/worker-utils/src/sandbox-allocation.ts - no issues (predicate moved verbatim from the Worker)
• packages/worker-utils/src/sandbox-allocation.test.ts - no issues
• services/cloud-agent-next/src/sandbox-selection.ts - no issues (single implementation, re-export keeps existing imports working)

Verified for context: apps/web/src/components/cloud-agent-next/sandbox-selection.ts, apps/web/src/components/cloud-agent-next/settings/settings-options.ts, and Worker callers of isSandboxAllocationAvailable.

Fix these issues in Kilo Cloud

Previous review (commit f565441)

Status: 3 Issues Found | Recommendation: Address before merge

Executive Summary

The sandbox picker can report a valid saved allocation as "no longer offered" while capabilities are loading or after the capabilities query fails; the remaining findings are a redundant capability request and a web/Worker availability-gate mismatch. No authorization, tenant-isolation, or data-exposure defects were found: organization membership is checked before the new gate, update ownership pins organizationId to the trigger's own organization, and the gate fails closed.

Assumptions: [INFERENCE] No pre-existing inline comments, reviews, or issue comments were present at review start. End-to-end delivery of vercel-* and cloudflare-containers-* allocations depends on Cloud Agent Next re-validating availability in prepareSession and forcing the control plane for non-Cloudflare providers (read, not executed). parseSandboxAllocation now throws for persisted values outside the widened enum, so rolling back webhook-agent-ingest after new allocations are saved would break config reads for affected triggers; the PR documents only the forward deployment order and no database migration is involved.

Overview

Severity	Count
CRITICAL	0
WARNING	1
SUGGESTION	2

Issue Details (click to expand)

WARNING

File	Line	Issue
apps/web/src/components/webhook-triggers/TriggerForm.tsx	178	showUnavailableSandbox treats missing capabilities (pending or failed) as an unavailable sandbox, showing a saved allocation as "(unavailable)" / "no longer offered" and inviting the user to clear it

SUGGESTION

File	Line	Issue
apps/web/src/app/(app)/cloud/webhooks/[triggerId]/EditWebhookTriggerContent.tsx	64	Capabilities query keyed on async triggerData issues an unused Worker request and re-enters an undefined state after the form renders; errors leave the picker silently unavailable
apps/web/src/routers/webhook-triggers-router.ts	337	Legacy carve-out exempts only isolated-standard, while the Worker's authoritative check also exempts cloudflare-single; re-sending an existing cloudflare-single allocation is rejected

Files Reviewed (15 files)

• apps/web/src/app/(app)/cloud/webhooks/[triggerId]/EditWebhookTriggerContent.tsx - 1 issue
• apps/web/src/app/(app)/cloud/webhooks/new/CreateWebhookTriggerContent.tsx - no issues (same query-key pattern, covered by the edit finding)
• apps/web/src/components/webhook-triggers/TriggerForm.tsx - 1 issue
• apps/web/src/components/webhook-triggers/TriggerForm.test.ts - no issues
• apps/web/src/lib/webhook-agent/webhook-agent-client.ts - no issues
• apps/web/src/lib/webhook-agent/webhook-agent-client.test.ts - no issues
• apps/web/src/routers/webhook-triggers-router.ts - 1 issue
• apps/web/src/routers/webhook-triggers-router.schema.test.ts - no issues
• services/webhook-agent-ingest/src/routes/api.ts - no issues
• services/webhook-agent-ingest/src/routes/api.test.ts - no issues
• services/webhook-agent-ingest/src/dos/TriggerDO.ts - no issues
• services/webhook-agent-ingest/src/queue-consumer.ts - no issues
• services/webhook-agent-ingest/src/queue-consumer.test.ts - no issues
• services/webhook-agent-ingest/test/integration/trigger-do.test.ts - no issues
• services/kilo-mcp/catalog.json - no issues (generated)

Verified separately: packages/worker-utils/src/sandbox-allocation.ts, apps/web/src/components/cloud-agent-next/settings/settings-options.ts, apps/web/src/components/cloud-agent-next/sandbox-selection.ts, services/cloud-agent-next/src/sandbox-selection.ts for contract/behavior context.

Fix these issues in Kilo Cloud

---

_{Reviewed by deepseek-flash-latest · Input: 249.2K · Output: 26.3K · Cached: 3M}

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