Description of the bug:
When migrating an existing project from the legacy version of AI Studio to the current
version, the platform unconditionally enforces the user’s Global Framework Setting
on the project being migrated — regardless of the framework the project was actually
built with.
Reproduction steps:
Set the Global Framework Setting in AI Studio to Next.js.
Open a separate, existing project built with React + Vite.
Trigger the platform migration for that project.
Observe that the migration injects Next.js-specific files into the Vite project:
next.config.ts
next-env.d.ts
/app directory
Attempt to build — the project fails due to conflicting framework configurations.
Environment:
Platform: Google AI Studio
Migration: Legacy → Current version
Project framework (actual): React + Vite
Global Framework Setting at time of migration: Next.js
What makes this critical:
The migration performs destructive file operations without any pre-migration backup
prompt. If the user has not manually exported their code beforehand, overwritten or
deleted files cannot be recovered.
Actual vs expected behavior:
Expected behavior:
Before applying any structural changes, the migration tool should:
Inspect the project’s package.json dependencies and file structure to detect the
framework already in use.
Apply only migration steps that are compatible with the detected framework.
If a conflict is found between the detected framework and the Global Setting, halt
the process and surface a clear warning before proceeding:
Warning: This project uses Vite/React, but your Global Framework Setting
is set to Next.js. Proceeding may cause build failures and file overwrites.
Please update your settings or confirm to continue.
Scope the Global Framework Setting to new projects only — never apply it
retroactively to projects with an established framework.
Actual behavior:
The migration blindly applies the Global Framework Setting to all projects, injecting
framework-specific config files and directory structures with no compatibility check,
no warning, and no rollback mechanism.
The result is a non-buildable hybrid codebase:
Any other information you’d like to share?
Impact:
Code corruption: A fully functional application is rendered non-buildable, with
no automated rollback or recovery option.
Permanent data loss: Users who have not manually exported their project prior to
migration may lose all development work with no path to recovery.
Compounded risk: In workflows where the project is also deleted from Google Drive
as part of the migration, there is no fallback copy of any kind.
Affects all multi-project users: Any developer maintaining projects across
multiple frameworks is at risk whenever the Global Setting does not match the project
being migrated.
Proposed fixes (in priority order):
Mandatory pre-migration backup prompt — Surface a “Download Project” dialog
before any migration begins. Require the user to either download the project or
explicitly confirm they have an existing backup before the migration can proceed.
Pre-migration framework detection — Scan package.json and the project file
tree to identify the framework in use. Block migration if a conflict is detected
and require explicit user confirmation to override.
Itemized consent for structural changes — Any step that adds, modifies, or
removes core config files (next.config.ts, vite.config.ts, etc.) must list
those changes explicitly and require per-item approval before executing.
Scope Global Setting to new projects only — The Global Framework Setting should
never be applied retroactively to projects that already have an established
framework.
Suggested labels: bug · data-loss · migration · needs-triage
Suggested severity: Critical — irreversible data loss possible with no user warning.