chore: end 2 end snapshot tests for generate and refactor

.eslint.package.json.js

@@ -5,5 +5,5 @@ module.exports = {
   rules: {
     'package-json-dependencies/alphabetically-sorted-dependencies': 'error',
   },
-  ignorePatterns: ['node_modules'],
+  ignorePatterns: ['node_modules', 'amplify-migration-apps'],
 };

.gitignore

@@ -107,3 +107,7 @@ packages/amplify-environment-parameters/lib/
 
 .nx/cache
 .nx/workspace-data
+
+reports/*.xml
+commit-msg.txt
+amplify-migration-apps/**/_snapshot.*.actual

.husky/pre-commit

@@ -7,6 +7,8 @@ CYAN='\033[0;36m'
 NC='\033[0m' # No color
 
 echo "${GREEN}Running pre-commit hook${NC}"
+echo "${CYAN}Running yarn sanitize-migration-apps"
+yarn sanitize-migration-apps
 echo "${CYAN}Running yarn prettier staged files${NC}"
 git diff --name-only --cached --diff-filter=ACM | grep -E '\.(js|jsx|ts|tsx)$' | xargs --no-run-if-empty yarn prettier --write
 echo "${CYAN}Running yarn lint-staged${NC}"

.kiro/skills/add-gen2-migration-generate-snapshot-test/SKILL.md

@@ -0,0 +1,26 @@
+---
+name: add-gen2-migration-generate-snapshot-test
+description: >
+  Use when adding a new snapshot test for the gen2-migration generate command.
+  Handles migration app setup, expected snapshot directory validation, test case
+  registration, and mock client troubleshooting.
+---
+
+## Workflow
+
+1. Read `amplify-migration-apps/README.md`, specifically the "Adding a Snapshot Test | `generate`" section. Follow those instructions.
+2. Read `packages/amplify-cli/src/__tests__/commands/gen2-migration/_framework/README.md` for test framework and mock client details.
+3. Add the test case to `packages/amplify-cli/src/__tests__/commands/gen2-migration/generate/codegen-head/command-handlers.test.ts`.
+4. Run the test and make the necessary changes until it passes.
+
+## Rules
+
+- Ask the user for the app name and whether it uses Amplify Hosting before writing the test case.
+- Do NOT generate the `amplify` or `_snapshot.post.generate/` directories — they must come from an actual migration run. If it doesn't exist, tell the user to run the migration first.
+- Do NOT make production code changes to fix test failures. Only adjust mocks or test configuration.
+- Do NOT make any behavioral changes to the expectation directory. This behavior was created and validated by the user already and must not change. You can however make syntax changes or ones needed due to the santiation process.
+- Only make code changes to the test itself or the test framework code.
+
+## Guidelines
+
+- Do NOT create TypeScript interfaces for Amplify Gen1 configuration structures (e.g., `cli-inputs.json`, `team-provider-info.json`, CloudFormation template shapes). These configs are numerous, inconsistent, and loosely typed. Use `any` with eslint-disable comments instead.

.prettierignore

@@ -19,6 +19,7 @@ packages/amplify-environment-parameters/src/schemas/BackendParameters.schema.jso
 packages/amplify-nodejs-function-runtime-provider/src/__tests__/utils/handlerWithSyntaxError.js
 packages/amplify-velocity-template/src/parse/velocity.yy
 packages/amplify-frontend-ios/tests/sample**
+amplify-migration-apps/**
 
 # Exceptions:
 !packages/amplify-category-hosting/lib

.vscode/extensions.json

@@ -1,5 +1,5 @@
 {
   // See http://go.microsoft.com/fwlink/?LinkId=827846
   // for the documentation about the extensions.json format
-  "recommendations": ["dbaeumer.vscode-eslint", "Orta.vscode-jest"]
+  "recommendations": ["dbaeumer.vscode-eslint", "Orta.vscode-jest", "esbenp.prettier-vscode"]
 }

.vscode/settings.json

@@ -1,12 +1,23 @@
 {
-  "editor.rulers": [140],
+  "editor.rulers": [
+    140
+  ],
+  "files.watcherExclude": {
+    "**/node_modules/**": true,
+  },
   "files.exclude": {
+    "**/node_modules": true,
     "**/.git": true,
-    "**/build": true
+    "**/build": false
   },
   "files.insertFinalNewline": true,
   "editor.formatOnSave": true,
-  "eslint.validate": ["javascript", "javascriptreact", "typescript", "typescriptreact"],
+  "eslint.validate": [
+    "javascript",
+    "javascriptreact",
+    "typescript",
+    "typescriptreact"
+  ],
   "eslint.lintTask.enable": true,
   "eslint.packageManager": "yarn",
   "eslint.quiet": false,
@@ -16,6 +27,7 @@
   "prettier.requireConfig": true,
   "prettier.configPath": "./.prettierrc",
   "search.exclude": {
+    "**/node_modules": true,
     "**/.yarn": true,
     "**/.pnp.*": true
   },

AGENTS.md

@@ -8,33 +8,48 @@ This is a TypeScript monorepo (Yarn 3 + Lerna) for AWS Amplify CLI Gen1.
 
 ## Standard Development Workflow
 
-__Research Stage__
+### 1. Research Stage
 
-1. Start by delegating to the `context-gatherer` agent (defined in `.kiro/agents/context-gatherer.json`) to identify the relevant files to this issue. The sub agent must report both the files relevant to the issue, and the docs files relevant to the issue, as well as any additional context necessary to the issue.
+Start by delegating a context-gatherer sub agent to identify the relevant files to this issue. The sub agent must report both the
+files relevant to the issue, and the docs files relevant to the issue, as well as any additional context necessary to the issue.
+When in doubt, ask the user clarifying questions. When you think you have enough context to implement the task, summarize it to the
+user and ask for confirmation before continuing.
 
-**Before changing code you MUST first reference the relevant docs/ files** Documentation is organized under `docs/` in the same path as the code it references:
-- For example `packages/amplify-cli/src/commands/drift.ts`: `docs/amplify-cli/drift.md`
+**Before changing code you MUST first reference the relevant docs/ files**. Documentation is organized under `docs/` in the
+same path as the code it references. For example
 
-__Implementation Stage__
+- `packages/amplify-cli/src/commands/drift.ts`: `docs/amplify-cli/drift.md`
 
-2. **CRITICAL: NO 'any' types allowed.** TypeScript strict mode is enforced throughout the project.
+### 2. Implementation Stage
 
-3. Use absolute imports for cross-package dependencies (`@aws-amplify/...`) and relative imports within the same package.
+Make the necessary code changes and follow the guidelines in [CODING_GUIDELINES](./CODING_GUIDELINES.md).
+For incremental validation, run `jest` commands directly and filter for the relevant tests.
 
-__Verification Stage__
+### 3. Verification Stage
 
-4. Always run `yarn build` before testing your changes. (Only ever build with yarn install && yarn build).
+Verify your changes by following these guidelines:
 
-5. Skip testing and manual verification, the engineer must do this.
+- Run `yarn test` in the package closest to the one you are working on.
+- No need to run `yarn build`. The unit tests are configured to execute the TypeScript files.
 
-__Commit Stage__
+### 4. Commit Stage
 
-6. **Always** update the appropriate README or design document when you make a change that impacts the contents of these documents.
-
-7. Do not create additional markdown files in the repository unless you are instructed explicitly to.
-
-8. Commit your changes in git using a well-formed commit message following the Conventional Commits format. The message must start with a type prefix (e.g., `feat:`, `fix:`, `docs:`, `refactor:`, `test:`, `chore:`) followed by a single sentence summary and no more than a few paragraphs explaining the change and your testing. After this explanation, place the prompt the user used to trigger this work prefixed with a "Prompt: " after a single line consisting of '---'. Make sure there are no empty lines before or after this line. Word wrap all paragraphs at 72 columns including the prompt. For the author of the commit, use the configured username in git with ' (AI)' appended and the user email. For example, `git commit --author="John Doe (AI) <john@bigco.com>" -m "docs: update configuration guide"`
+- **Always** update the appropriate README or design document when you make a change that impacts the contents of these documents.
+- **Always** update the appropriate skill files when you make a change that impacts the contents of the skill (path to docs for example).
+- **Always** update the appropriate JSDoc strings in the code you change. Be concise.
+- Do not create additional markdown files in the repository unless you are instructed explicitly to.
+- Commit your changes in git using a well-formed commit message following the Conventional Commits format. The message must start
+  with a type prefix (e.g., `feat:`, `fix:`, `docs:`, `refactor:`, `test:`, `chore:`) followed by a single sentence summary and no more
+  than a few paragraphs explaining the change and your testing. After this explanation, place the prompt the user used to trigger this
+  work prefixed with a "Prompt: " after a single line consisting of '---'. Make sure there are no empty lines before or after this line.
+  Word wrap all paragraphs at 72 columns including the prompt. For the author of the commit, use the configured username in git with
+  ' (AI)' appended and the user email. For example, `git commit --author="John Doe (AI) <john@bigco.com>" -m "docs: update configuration guide"`.
+  To avoid issues with multi-line commit messages, always create a `commit-msg.txt` file and commit
+  with `-F` (delete the `commit-msg.txt` file afterwards).
 
+- Since this repo has a commit hook that takes quite a long time to run, don't immediately commit every
+  change you were asked to do. Apply your judgment, if the diff is still fairly small just keep going.
+  Otherwise, ask the user if they want to commit or keep going.
+- Before you actually commit, provide a (very) concise summary of changes to the user and ask for confirmation to commit.
 
 **ALWAYS FOLLOW THESE RULES WHEN YOU WORK IN THIS PROJECT**
-