kirodotdev · nadetastic · Jul 24, 2026 · Jul 24, 2026 · Jul 24, 2026
diff --git a/aws-transform/POWER.md b/aws-transform/POWER.md
@@ -4,7 +4,7 @@ displayName: "AWS Transform"
 description: "Migrate, modernize, and upgrade codebases: .NET Framework to .NET 8/10, mainframe COBOL to Java, VMware VMs to EC2, SQL Server/Oracle/MySQL to Aurora, and Java/Python/Node.js version upgrades or AWS SDK migrations. Assess, plan, and execute code transformations from your IDE."
 keywords: ["migrate", "modernize", "mainframe", "cobol", "vmware", "dotnet", ".net framework", "windows", "sql server", "oracle", "mysql", "aurora", "ec2 migration", "rehost", "lift-and-shift", "replatform", "legacy", "code upgrade", "sdk migration", "boto3", "java upgrade", "atx", "continuous modernization", "AWS Transform - continuous modernization"]
 author: "AWS"
-version: "2.3.0"
+version: "2.4.0"
 ---
 
 # AWS Transform Power
@@ -98,24 +98,53 @@ Once routed to continuous modernization:
 
 1. **First-response telemetry notice (once per session).** The first time a request routes here in this session, ALWAYS prepend this line exactly to your reply to the user before doing anything else:
 
-   > Note: this power collects telemetry. To opt out, see [here](https://docs.aws.amazon.com/transform/latest/userguide/transform-usage-telemetry.html).
+   > Note: this power and the continuous modernization CLI, (`atx ct`), collect usage telemetry by default during transformation execution. The telemetry consists of different data points, such as, the IDE name (for example, VS Code or Kiro), the AI agent name (for example, Claude Code or OpenAI Codex), and the execution mode (local or remote). This data is used by AWS Transform to prioritize compatibility testing, as well as latency and reliability. To opt out, see [here](https://docs.aws.amazon.com/transform/latest/userguide/transform-usage-telemetry.html).
+
+   Show it exactly once per session. Do NOT repeat it on subsequent continuous modernization requests in the same session.
+
+   **Telemetry opt-out.** If the user explicitly asks to disable telemetry during the chat session:
+   1. Omit `--telemetry` for the rest of the session (see each `workload-continuous-modernization-*.md` file's Telemetry section for the flag format).
+   2. Prepend `ATX_DISABLE_TELEMETRY=true` inline on **every** `atx ct` command for the rest of the session — not only `analysis`/`remediation`, but also setup and diagnostic commands like `atx ct status`, `atx ct source ...`, and `atx ct setup ...`. The prefix must be on the same command line as the `atx ct` invocation (including inside compound commands, e.g. `which atx && ATX_DISABLE_TELEMETRY=true atx ct ...`), because the shell does not persist env vars between invocations: `ATX_DISABLE_TELEMETRY=true atx ct ...`
 
-   Show it exactly once per session. Do NOT repeat it on subsequent continuous modernization requests in the same session. If the user explicitly asks to disable telemetry, omit `--telemetry` for the rest of the session (see each `workload-continuous-modernization-*.md` file's Telemetry section for the flag format).
 2. When invoking AWS Transform - continuous modernization (continuous modernization) commands, use `atx ct` (with a space). `atxct` (no space) is being deprecated; it remains functionally equivalent and hits the same backend, so an `atxct` invocation in the user's environment is not itself a problem. Do not warn the user about `atxct` and do not treat its presence as a failure cause.
-3. Check if `atx ct` is installed AND up to date — run as a single command:
+
+3. **Verify local CLI dispatch before checking versions or AWS configuration.** Run this without redirecting stderr:
 
    ```
-   INSTALLED=$(atx ct --version 2>/dev/null | head -1); LATEST=$(curl -fsSL "https://transform-cli.awsstatic.com/index.json" 2>/dev/null | grep -o '"latest"[[:space:]]*:[[:space:]]*"[^"]*"' | sed 's/.*"latest"[[:space:]]*:[[:space:]]*"\([^"]*\)".*/\1/'); echo "Installed: ${INSTALLED:-not found}, Latest: ${LATEST:-unknown}"
+   atx ct --version
    ```
-4. If `INSTALLED` is empty or `LATEST` is newer: `curl -fsSL https://transform-cli.awsstatic.com/install.sh | bash && source ~/.bashrc`
-5. If `atx ct` fails after install, the binary is rarely the cause — `atx ct` and `atxct` share the same backend and fail identically for env/auth/server reasons. Check those first:
-   - `ATXCT_FES_ENDPOINT` is set on the server process (not just the CLI shell)
+
+   Classify failures before continuing:
+   - If the shell reports `atx: command not found`, install the AWS Transform CLI: `curl -fsSL https://transform-cli.awsstatic.com/install.sh | bash`, then restart the shell or source its profile.
+   - If an `atx` process runs but reports `unknown command 'ct'`, do NOT reinstall blindly or investigate AWS credentials/region. Follow the [command-resolution troubleshooting](steering/workload-continuous-modernization-troubleshooting.md#atx-ct-reports-unknown-command-ct) first.
+   - If the command succeeds, continue with the version comparison.
+
+4. Check whether the working CLI is up to date:
+
+   ```
+   INSTALLED=$(atx ct --version | head -1); LATEST=$(curl -fsSL "https://transform-cli.awsstatic.com/index.json" 2>/dev/null | grep -o '"latest"[[:space:]]*:[[:space:]]*"[^"]*"' | sed 's/.*"latest"[[:space:]]*:[[:space:]]*"\([^"]*\)".*/\1/'); echo "Installed: ${INSTALLED:-not found}, Latest: ${LATEST:-unknown}"
+   ```
+
+   If `LATEST` is known and newer than `INSTALLED`, update with `curl -fsSL https://transform-cli.awsstatic.com/install.sh | bash`, then restart the shell or source its profile.
+
+5. **Credential preflight.** Validate AWS credentials before starting any analysis or remediation — at minimum on the first continuous modernization request of the session (new or returning users), and again before any later run in a long session, since credentials can lapse mid-session:
+
+   ```
+   aws sts get-caller-identity
+   ```
+
+   If it fails or the credentials are expired, refresh them before continuing. Do NOT start any long-running work on expired or soon-to-expire credentials — an analysis started on credentials about to expire can strand the run mid-flight. Run the preflight silently; surface it to the user only if the credentials need refreshing.
+
+6. If local `atx ct` dispatch succeeded but a later command fails, then check runtime configuration:
    - `AWS_PROFILE` points at a valid account with refreshed credentials
-   - The server is running (`atx ct status --health`)
+   - `AWS_REGION` is set to a supported region
+   - `ATX_CUSTOM_ENDPOINT` is set in the environment (only if you use a custom endpoint)
+
+   An `unknown command 'ct'` failure is a local command-resolution problem, not an AWS configuration problem; return to Step 3 instead.
+
+7. Ensure a supported region has been selected (see [workload-continuous-modernization-setup.md](steering/workload-continuous-modernization-setup.md) "Choose your region") and prefixed inline (`AWS_REGION=$ATX_REGION`) on every `atx ct` command.
 
-   Only after those check out, verify `atx --help` shows the `ct` subcommand and that `atxct-plugin.mjs` is co-located with the `atx` binary.
-6. Start the server using the [continuous-modernization-server.md](steering/workload-continuous-modernization-server.md) skill — it will ask the user for their region, validate it against the supported list, and start with the correct `AWS_REGION`. Wait 5s, then verify with `atx ct status --health`.
-7. Then use the appropriate continuous modernization steering file — see `steering/workload-continuous-modernization-routing.md` and the `workload-continuous-modernization-*.md` files referenced from it.
+8. Then use the appropriate continuous modernization steering file — see `steering/workload-continuous-modernization-routing.md` and the `workload-continuous-modernization-*.md` files referenced from it.
 
 **When in doubt for a workload-unspecified request → continuous modernization.** This default applies ONLY after Step B has cleared — VMware, SQL, and mainframe never fall through to continuous modernization regardless of how the question is phrased; .NET only routes to continuous modernization after the user picks "analyze for tech debt / security / CVEs" in Step B's intent question (both "Modernize" and "Assessment for modernization" stay in the .NET workload). Once routed, do NOT manually read source files to find issues — that's what `atx ct analysis run` does.
 

diff --git a/aws-transform/steering/auth.md b/aws-transform/steering/auth.md
@@ -36,6 +36,12 @@ Common CLI-side conditions:
 - `AccessDeniedException` → AWS credentials expired. Re-run `aws sso login` or refresh env vars.
 - `command not found: atx` → CLI not installed. Use MCP-based transforms instead, or install the CLI.
 
+### WSL: separate AWS config on the Linux and Windows sides
+
+On Windows, running the CLI inside WSL introduces a common footgun. WSL's Linux home directory and the Windows user profile each hold their **own** `~/.aws/config` (WSL: `~/.aws/config`; Windows: `C:\Users\<user>\.aws\config`). `aws sso login` refreshes the cached SSO token only for the environment it was run in — a login in Windows PowerShell does not produce a token the WSL side can read, and vice versa.
+
+When a user on Windows/WSL reports `AccessDenied`, expired-token, or "no credentials" errors from `atx` or `aws` **despite having signed in**, suspect this split before generic re-auth advice. Confirm which environment they run `atx` in (the WSL shell) versus where they ran `aws sso login`. The fix: run `aws sso login --profile <profile>` **in the same WSL shell** where `atx` runs, so it reads the WSL-side `~/.aws/config` and caches the refreshed token under that side's `~/.aws/sso/cache/`. Verify from that same shell with `aws sts get-caller-identity`. (If a user deliberately shares one config across both sides, they must set `AWS_CONFIG_FILE`/`AWS_SHARED_CREDENTIALS_FILE` to the shared path in every shell — but same-environment login is the simpler default.)
+
 ## Environment variables (MCP client config)
 
 Pre-set in `mcp.json` to skip an interactive `configure` call:

diff --git a/aws-transform/steering/workload-continuous-modernization-analysis.md b/aws-transform/steering/workload-continuous-modernization-analysis.md
@@ -33,11 +33,11 @@ If the user explicitly asks to disable telemetry, omit `--telemetry` for the res
 - **EC2** -- follow [continuous-modernization-ec2-execution](workload-continuous-modernization-ec2-execution.md)
 - **Batch** -- follow [continuous-modernization-batch-execution](workload-continuous-modernization-batch-execution.md)
 
-## Repository limit per request (max 250)
+## Repository limit per request (max 100)
 
-A single `atx ct analysis run` can be associated with at most **250 repositories**. Before starting an analysis that targets many repos (for example a whole source), check how many repositories are in scope — `atx ct source list` or `atx ct repository list --source <name>` report the per-source count. (Bare `atx ct status` shows workspace-wide totals across all sources, so prefer a scoped form when the analysis targets a single source.)
+A single `atx ct analysis run` can be associated with at most **100 repositories**. Before starting an analysis that targets many repos (for example a whole source), check how many repositories are in scope — `atx ct source list` or `atx ct repository list --source <name>` report the per-source count. (Bare `atx ct status` shows workspace-wide totals across all sources, so prefer a scoped form when the analysis targets a single source.)
 
-If the scope exceeds 250 repositories, split it into multiple runs, each targeting at most 250 repos (pass the repos in batches via `--repo <source>::<slug>`), and tell the user you are breaking the work up because of the 250-repo-per-request limit. Never issue a single run associated with more than 250 repositories — it will be rejected. Example: 300 repos → two runs (250 + 50); 600 repos → three runs (250 + 250 + 100).
+If the scope exceeds 100 repositories, split it into multiple runs, each targeting at most 100 repos (pass the repos in batches via `--repo <source>::<slug>`), and tell the user you are breaking the work up because of the 100-repo-per-request limit. Never issue a single run associated with more than 100 repositories — it will be rejected. Example: 300 repos → three runs (100 + 100 + 100); 600 repos → six runs (100 each).
 
 ## Commands
 
@@ -86,6 +86,8 @@ atx ct analysis run --type tech-debt-comprehensive --source <name> --wait --tele
 tail -f /tmp/atx-analysis.log
 ```
 
+The redirect captures the command's diagnostics — the in-process CLI writes logs to STDERR, which `2>&1` folds into the log file. Only warnings and errors are logged by default; when troubleshooting, prefix the command with `ATXCT_LOG_LEVEL=debug` for verbose output (e.g. `ATXCT_LOG_LEVEL=debug atx ct analysis run ... > /tmp/atx-analysis.log 2>&1 &`).
+
 This applies to comprehensive scans, large multi-repo runs, and any analysis the user expects to take a while. Tell the user where the log is and how to check progress.
 
 ## Custom Analysis
@@ -148,39 +150,13 @@ When polling with `atx ct analysis get --id <id> --json`, the `status` field is
 
 **Note:** It's `complete`, NOT `COMPLETED` or `completed`.
 
-## Artifacts
-
-After an analysis completes, its report artifacts can be listed and retrieved:
-
-```bash
-# List all artifacts for an analysis
-atx ct analysis list-artifacts --id <analysis-id> --json
-
-# Get content of a specific artifact
-atx ct analysis get-artifact --id <analysis-id> --repo <source>::<slug> --name <artifact-name>
-```
-
-### Artifact names by analysis type
-
-| Analysis Type           | Artifact Names                                                                                                                                                               |
-| ----------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| tech-debt-comprehensive | `report`, `technical-debt-report/summary`, `technical-debt-report/outdated-components`, `technical-debt-report/maintenance-burden`, `technical-debt-report/remediation-plan` |
-| agentic-readiness       | `ara` (per repo); `_portfolio_ara` (portfolio-level)                                                                                                                         |
-| modernization-readiness | `mod` (per repo); `_portfolio_mod` (portfolio-level)                                                                                                                         |
-
 ## After Analysis Completes
 
 Once an analysis finishes, retrieve its findings by analysis ID and summarize for the user:
 
 ```bash
 # Get findings produced by a specific analysis
 atx ct findings list --analysis-id <analysis-id> --json
-
-# List artifacts to see available reports
-atx ct analysis list-artifacts --id <analysis-id> --json
-
-# Read a specific report
-atx ct analysis get-artifact --id <analysis-id> --repo <source>::<slug> --name report
 ```
 
 ## When an analysis returns 0 findings
@@ -223,3 +199,21 @@ If an analysis returns 0 findings on a repo that's obviously stale (Java 8, Node
 ### Pagination (nextToken)
 
 Depending on the CLI version, `atx ct analysis list` may return only a bounded page rather than every result — don't assume a fixed response shape. After each call, check whether the response carries a `nextToken`; if it's present and non-empty, call the command again with `--next-token <token>` and repeat until no `nextToken` remains. Never treat the first page as the complete set when a `nextToken` is present, or you'll silently miss analyses.
+
+## Tags (resource tagging)
+
+The `--tags` flag attaches IAM resource tags to an analysis at creation time, and propagates those tags through to any findings the analysis produces.
+
+```bash
+# Run analysis with tags (comma-separated key=value pairs)
+atx ct analysis run --type tech-debt-comprehensive --source <name> --tags team=alpha,env=prod --wait --telemetry "agent=<AGENT>,executionMode=local"
+```
+
+**Behavior:**
+
+- `--tags key=value,key2=value2` accepts comma-separated pairs in a single flag (e.g. `--tags team=alpha,env=prod`).
+- Tags are optional. If omitted, the analysis and its findings are untagged.
+- Tags are injected into the `--atxct-configuration` payload passed to the transformation agent. When the agent calls `report_finding`, the tags are forwarded to `BatchCreateFindings` — so findings inherit the analysis's tags automatically.
+- If `~/.aws/atx/settings.json` defines `applyTags` (an array of tag maps), those defaults are applied automatically even without explicit `--tags`. An explicit `--tags` override merges **per key** over the settings defaults.
+
+See the [source](workload-continuous-modernization-source.md) skill's Tags section for the full schema, merge semantics, and error behavior.