Launch Wizard Inline Dependencies v1¶
Status: accepted for v3 production migration.
Decision¶
Launch wizards must resolve missing prerequisites inside the wizard whenever the dependency can be safely created with existing project/account authority. Users should not leave the launch flow to add an SSH key, bucket, or service account, then restart the wizard.
Initial Production Scope¶
The first production pass wires these inline dependencies:
| Dependency | Surfaces | API owner | Wizard behavior |
|---|---|---|---|
| SSH public key | Compute launch, app launch | Account security | Select existing personal/project keys or add a public key inline. The created key is selected immediately. |
| Storage bucket | Compute launch, app launch | V3 storage | Select existing buckets with owned/shared treatment or create a project bucket inline. Advanced storage creation remains available at /v3-prod/launch/storage. |
| Service account | App launch, storage launch | Access/IAM | Select an active project operator/automation service account or create one inline. The returned one-shot credential is shown only in component state and is not stored in the wizard draft. |
Network policy, firewall rules, public IPs, load balancers, and VPN attachments remain visible as future dependency kinds. They should follow the same pattern once their backend contracts exist.
UX Rules¶
- Inline creation must not reset wizard draft state.
- Previous steps remain clickable; future steps remain gated.
- Created resources are selected immediately and the relevant list query is invalidated.
- One-shot credential material must not be cached in React Query, localStorage, sessionStorage, or wizard drafts.
- If a dependency requires a richer setup than the inline form can safely express, the wizard links to the full workbench but keeps the draft.
API Boundary¶
V3 launch pages continue to use /api/v1/v3/* for shell, read models,
precheck, submit, task routing, and storage mutations. SSH-key and
service-account creation currently use their existing domain APIs because those
contracts are already stable and audited. If those domain APIs are later wrapped
with V3-specific dependency endpoints, the UI component boundary is already
centralized in launch-inline-dependencies.tsx.
E2E Contract¶
V3 E2E tests keep the fail-closed /backend/** mock harness. The launch
dependency domain APIs are explicitly mocked in the harness so accidental
unmocked V1 page calls still fail. Tests assert stable data-testid selectors
for:
- selected SSH key rows,
- inline SSH key creator,
- selected service-account rows,
- inline service-account creator,
- inline storage bucket creator.