feat(#22): should add support for cloud compute

specs/22_should-add-support-for-cloud-compute/brainstorm_transcript.md

@@ -0,0 +1,72 @@
+# Brainstorm Transcript: Issue #22
+
+## Session
+
+- Date: 2026-03-27
+- Mode: discovery-recovery
+- Goal: close testability gaps so acceptance criteria become implementation-ready.
+
+## Q1
+
+What is the minimum shippable slice for this issue:
+
+1. abstraction/interface scaffolding only,
+2. abstraction + one hosted provider integration (EigenCompute), or
+3. abstraction + hosted + local fully wired end-to-end?
+
+### A1
+
+`3` - abstraction + hosted + local fully wired end-to-end.
+
+## Q2
+
+For hosted provider scope in this issue, should it be:
+A) EigenCloud only, or
+B) provider wizard with multiple hosted providers?
+
+### A2
+
+Provider wizard with multiple hosted providers, not EigenCloud only.
+Initial targets: EigenCloud, DigitalOcean, and AWS.
+
+## Q3
+
+For local provider behavior, what is the required rule for this issue?
+A) auto-fallback to local when cloud is unavailable
+B) no auto-fallback, explicit local selection only
+C) both with a configurable toggle
+
+### A3
+
+`C` - both with a configurable toggle.
+
+## Q4
+
+For this issue's MVP depth:
+A) real provisioning integration for EigenCloud, AWS, and DigitalOcean, or
+B) provider wizard + provider interface + validated adapter wiring, with real provisioning for one provider and stubs for others.
+
+### A4
+
+`A` - real provisioning integration for EigenCloud, AWS, and DigitalOcean.
+
+## Q5
+
+Pick the minimum liveness acceptance target for this issue:
+A) successful sandbox creation in < 120s for each provider + healthcheck pass
+B) successful sandbox creation in < 60s for each provider + healthcheck pass
+C) custom target
+
+### A5
+
+`B` - successful sandbox creation in < 60s for each provider + healthcheck pass.
+
+## Q6
+
+For the configurable local fallback toggle, what should be the default?
+A) default ON (auto-fallback to local when cloud fails)
+B) default OFF (explicit local selection required)
+
+### A6
+
+`A` - default ON (auto-fallback to local when cloud fails).

specs/22_should-add-support-for-cloud-compute/design_review_summary.md

@@ -0,0 +1,48 @@
+# Design Review Summary: Issue #22
+
+## Metadata
+
+- Date: 2026-04-08
+- Input: `specs/22_should-add-support-for-cloud-compute/design_spec.md`
+- Phase: 5 (Design review)
+
+## Lens 1: UX Research
+
+- Primary user goals are represented: selection, configuration, status visibility, and failure recovery.
+- Flow accounts for first-time setup and settings-based updates.
+- No blocker found.
+
+## Lens 2: Interaction Design
+
+- End-to-end flow is deterministic and includes fallback branches.
+- Step transitions and disable/enable rules for submission are explicit.
+- No blocker found.
+
+## Lens 3: Accessibility
+
+- Keyboard navigation, labels, live-region updates, and non-color status indicators are defined.
+- Mobile touch target and responsive constraints are included.
+- No blocker found.
+
+## Lens 4: Visual/Brand
+
+- Component inventory is cohesive and supports clear status storytelling.
+- Placeholder references exist for visual design handoff artifacts.
+- No blocker found.
+
+## Lens 5: Frontend Engineering
+
+- Components are decomposed into implementable units (`ProviderSelector`, `ProviderConfigForm`, `FallbackPolicyToggle`, `ProvisioningTimeline`).
+- State and behavior boundaries are clear for implementation and testing.
+- No blocker found.
+
+## Gate Decision
+
+- `design_completeness_gate`: **passed**
+- `design_approval`: **pending human approval**
+
+## Non-Blocking Follow-Ups
+
+- Finalize exact field schema names during technical spec phase.
+- Define canonical provider ordering constant to avoid UI drift.
+- Confirm copy strings with docs/content owner before implementation freeze.