feat(gen2-migration): full e2e execution of all apps

[iliapolo]

Description of changes

Rewrites the gen2-migration e2e system and restructures all migration apps. The goal is to make the e2e workflow simpler to understand, debug, and extend.

---

E2E System (amplify-gen2-migration-e2e-system)

1. Replace category initializer with snapshot restore

Before:

Each migration app had a migration-config.json — a custom DSL that described the app's categories in a JSON schema the e2e system invented:

{
  "categories": {
    "auth": { "signInMethods": ["phone"], "socialProviders": [] },
    "api": { "type": "GraphQL", "authModes": ["API_KEY"], "schema": "schema.graphql" },
    "storage": { "buckets": [...], "tables": [{ "name": "activity", "partitionKey": "id", "gsi": [...] }] },
    "function": { "functions": [{ "name": "fetchuseractivity", "runtime": "nodejs", "template": "hello-world" }] }
  }
}

The CategoryInitializer (644 lines) parsed this DSL and translated each entry into the corresponding @aws-amplify/amplify-e2e-core helper call (addAuthWithEmail, addApi, addS3Storage, addDynamoDBWithGSIWithSettings, addFunction, addLambdaTriggerWithModels, etc.). This required maintaining a mapping layer between the DSL and the e2e-core prompt-driven helpers — every new category feature or CLI prompt change required updating both the DSL schema and the translator. The DSL also couldn't express everything the CLI supports (auth triggers, custom roles, complex storage configurations), so apps that needed those features required workarounds.

After:

The e2e system restores the pre-generate snapshot (_snapshot.pre.generate/amplify/) directly into the amplify/ directory after amplify init. This gives us the exact Gen1 project state — all categories, all resources, all configuration — without running any amplify add commands. The App.configure() method handles merging the init-generated metadata (CloudFormation provider info, environment config) with the snapshot's backend definitions.

This eliminates CategoryInitializer, ConfigurationLoader, the types/index.ts DSL definitions (227 lines), and all migration-config.json files across every app.

2. Consolidate into a single App class

Before:

The e2e system was spread across 15+ files: cli.ts (657 lines of orchestration), AmplifyInitializer, CategoryInitializer, ConfigurationLoader, AppSelector, CDKAtmosphereIntegration, Gen2MigrationExecutor, EnvironmentDetector, DirectoryManager, FileManager, AWSProfileManager, Logger, types/index.ts, plus unit tests and e2e tests for each. Total: ~4,400 lines.

After:

Three files: App (owns the full lifecycle), Git (commit/checkout), Logger. Total: ~650 lines. The migration workflow in cli.ts reads as a flat sequence of method calls:

await app.init();
await app.configure();
await app.push();
await app.testGen1();
await app.assess();
await app.lock();
await app.generate();
await app.deployGen2Sandbox();
await app.refactor(gen2StackName);
// ...

Atmosphere support removed

The CDKAtmosphereIntegration class and all atmosphere-related code paths are removed. We haven't determined whether atmosphere will actually be used in the migration workflow, and carrying its maintenance overhead — wiring, configuration surface, test coverage — isn't justified while that decision is still open. The code is in git history and can be restored straightforwardly if we decide to adopt it.

E2E test ordering

testGen1 and testGen2 now run immediately after refactor, before gitCheckoutGen2/postRefactor. This validates both environments right after the refactor completes.

---

Migration Apps (amplify-migration-apps/)

3. Replace custom test scripts with Jest suites

Before:

Each app had three files for testing: test-utils.ts (a factory that created test functions and an orchestrator), gen1-test-script.ts, and gen2-test-script.ts. The gen1/gen2 scripts were nearly identical — they differed only in which config file they imported. The test-utils files were 300-700 lines each, with a custom TestRunner class, manual console logging, and process.exit(1) on failure. A shared _test-common/ directory provided signup.ts and runner.ts that all apps imported via relative paths.

After:

Each app has a tests/ directory with standard Jest test files (api.test.ts, storage.test.ts, etc.) and its own signup.ts tailored to its auth config. The same test files run against both Gen1 and Gen2 — the APP_CONFIG_PATH env var controls which config is loaded. npm scripts test:gen1 and test:gen2 set this variable. The shared _test-common/ directory is removed.

4. Expose migration scripts as npm scripts

Before:

The e2e system dynamically imported each app's post-generate.ts and post-refactor.ts from the source app directory using import(). The scripts accepted an options object ({ appPath, envName }) and the e2e system had to know the function signature.

After:

Each app's package.json defines npm scripts (post-generate, post-refactor, post-push) that the e2e system runs via npm run <script>. Apps that don't need a step set it to "true". The e2e system doesn't need to know anything about the scripts' internals.

5. Restructure backend assets

Backend source files (GraphQL schemas, Lambda function code, configure scripts) moved from the app root into a backend/ subdirectory. This separates backend assets from test files, migration scripts, and app source code.

---

CLI Fixes (amplify-cli)

Fix lock failing to find GraphQL API (#14560)

fetchGraphQLApiId matched APIs by name using the pattern ${appName}-${envName}, which isn't guaranteed to match the actual AppSync API name. When it didn't match, the API was silently missed and DynamoDB model tables never got deletion protection enabled. The new findGraphQLApiId reads the API ID directly from amplify-meta.json (the source of truth) instead of scanning ListGraphqlApis with a name heuristic.

Fix refactor deleting user pool triggers (#14750)

The update() method passed Tags: [] to UpdateStackCommand, which wiped out existing stack tags and triggered an UPDATE event on every resource in the template. For Cognito user pools, this was destructive: LambdaConfig (auth triggers) is defined in a separate stack and not present in the auth stack template, and Cognito's UpdateUserPool API doesn't support PATCH semantics — it replaces the entire configuration. The combination caused auth triggers to be silently deleted. The fix removes the Tags: [] parameter. Additionally, stack updates now use ExecuteChangeSet instead of UpdateStackCommand, so a truly empty change set results in a no-op rather than a spurious update.

Fix refactor --rollback failing with false duplicate-resource error (#14751)

refactor --rollback failed with "Resource already exists in Gen2 stack" because RollbackCategoryRefactorer.afterMove() checked whether the target stack already contained the resource being moved. This check ran during planning, before any moves had executed — so the resource was naturally still present in the Gen2 stack. The fix removes the premature check from the rollback planner and moves the duplicate-resource guard into Cfn.refactor(), which runs at execution time when the stack state is current. The bug was introduced in PR #14698 and wasn't caught because snapshot tests don't exercise rollback scenarios.

Cursor restore on SIGINT

SpinningLogger now registers a SIGINT handler that stops the spinner before exiting. Previously, Ctrl-C during a spinner-active migration step left the terminal cursor hidden.

Output formatting

Minor improvements to assess, lock, and refactor CLI output (spacing, colors).

Issue #, if available

#14560, #14750, #14751

Description of how you validated changes

Ran the full e2e migration workflow against all migration apps.

Checklist

• PR description included
• yarn test passes
• Tests are changed or added
• Relevant documentation is changed or added (and PR referenced)
• New AWS SDK calls or CloudFormation actions have been added to relevant test and service IAM policies
• Pull request labels are added

---

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.