Public launch scope completion

Problem

The Cloud Suite's workspace and onboarding UX has known gaps in production-safety behavior that must be resolved before public launch. Issues include incomplete error handling for edge cases in account/project setup, missing rollback mechanisms for failed operations, and workflows that work in development but are not resilient under real-world conditions (concurrent users, network failures, partial state). Launching with these gaps risks data loss, broken user states, and an inability to recover without manual database intervention.

Context

• The backlog for hosted onboarding, collaboration, and account/project workspace UX is broader than what public launch can safely absorb, so this task has to separate launch-critical scope from attractive but deferrable work.
• A credible launch needs stable default behavior, explicit unsupported cases, and a rollback story for the riskiest surfaces rather than a promise to finish everything.
• Expected touchpoints include apps/cloud/, templates/browser flows, auth/account docs, and cloud tests, launch checklists, and any tasks or docs that currently blur the line between required launch scope and post-launch follow-up.

Possible Solutions

• A - Keep the full backlog in scope until the last minute: preserves ambition, but guarantees launch risk remains unclear.
• B - Recommended: define a minimum externally supportable launch scope and close only those blockers: make explicit deferrals, owner assignments, and rollback expectations.
• C - Shrink scope aggressively to the point of a weak launch: lowers risk, but may undercut the product story and user value.

Plan

1. Audit the open work for hosted onboarding, collaboration, and account/project workspace UX and classify each item as launch-critical, launch-adjacent, or post-launch follow-up.
2. Document the required launch behaviors, known unsupported cases, and any rollback or kill-switch expectations for high-risk areas.
3. Close or explicitly defer the remaining blockers, linking each deferral to a tracked follow-up with clear risk notes.
4. Reconcile the launch scope with docs, QA/review evidence, and operator expectations so launch readiness is credible and explainable.

Implementation Progress

Review Feedback

• [ ] Review cleared