fix(aws-transform): align continuous-modernization steering with current atx CLI

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.7.0"
+version: "2.8.0"
 ---
 
 # AWS Transform Power

aws-transform/steering/workload-continuous-modernization-analysis.md

@@ -1,6 +1,6 @@
 ---
 name: analysis
-description: Run/start/restart/cancel/delete analyses (tech-debt-quick, tech-debt-comprehensive, security, agentic-readiness, modernization-readiness, custom). Detects vulnerabilities, outdated dependencies, migration opportunities, modernization candidates. Custom type runs any TD.
+description: Run/start/restart/cancel/delete analyses (rapid-techdebt-analysis, tech-debt-comprehensive, security, agentic-readiness, modernization-readiness, custom). Detects vulnerabilities, outdated dependencies, migration opportunities, modernization candidates. Custom type runs any TD.
 ---
 
 name: analysis
@@ -46,10 +46,10 @@ If the scope exceeds 100 repositories, split it into multiple runs, each targeti
 
 ```bash
 # Run analysis. Pass --wait so the command blocks until the run finishes (preferred — see "Running long analyses" below).
-atx ct analysis run --type <tech-debt-quick|tech-debt-comprehensive|security|agentic-readiness|modernization-readiness|custom> --source <name> [--repo <source>::<slug>] --wait --telemetry "agent=<AGENT>,executionMode=local"
+atx ct analysis run --type <rapid-techdebt-analysis|tech-debt-comprehensive|security|agentic-readiness|modernization-readiness|custom> --source <name> [--repo <source>::<slug>] --wait --telemetry "agent=<AGENT>,executionMode=local"
 
 # --wait is only in newer CLI versions. If it isn't supported, run the same command without --wait.
-atx ct analysis run --type <tech-debt-quick|tech-debt-comprehensive|security|agentic-readiness|modernization-readiness|custom> --source <name> [--repo <source>::<slug>] --telemetry "agent=<AGENT>,executionMode=local"
+atx ct analysis run --type <rapid-techdebt-analysis|tech-debt-comprehensive|security|agentic-readiness|modernization-readiness|custom> --source <name> [--repo <source>::<slug>] --telemetry "agent=<AGENT>,executionMode=local"
 
 # Run custom analysis with a specific transformation definition
 atx ct analysis run --type custom --transformation-name <TD-name> --source <name> --repo <source>::<slug> --wait --telemetry "agent=<AGENT>,executionMode=local"
@@ -65,7 +65,7 @@ atx ct analysis list --json
 
 # Filter on the server-side index (fast). Combine as needed.
 atx ct analysis list --status <pending|running|complete|cancelled|failed> --json
-atx ct analysis list --type <tech-debt-quick|tech-debt-comprehensive|security|agentic-readiness|modernization-readiness|custom> --json
+atx ct analysis list --type <rapid-techdebt-analysis|tech-debt-comprehensive|security|agentic-readiness|modernization-readiness|custom> --json
 atx ct analysis list --status complete --type security --json
 
 # Category is filtered client-side (does not reduce the fetch); only narrows what's printed.
@@ -165,7 +165,7 @@ When the user asks to run a custom analysis or mentions a capability not covered
 
 ### When to use TD discovery vs built-in types
 
-- If the user's request clearly maps to a built-in type (`tech-debt-quick`, `tech-debt-comprehensive`, `security`, `agentic-readiness`, `modernization-readiness`), use that type directly -- do NOT use custom.
+- If the user's request clearly maps to a built-in type (`rapid-techdebt-analysis`, `tech-debt-comprehensive`, `security`, `agentic-readiness`, `modernization-readiness`), use that type directly -- do NOT use custom.
 - If the request mentions a specific capability not covered by built-in types, or asks about custom/customer-owned TDs, use TD discovery.
 - If the user explicitly names a TD, skip discovery and run it directly with `--type custom --transformation-name <TD>`.
 
@@ -206,7 +206,7 @@ A `0 findings` result does NOT automatically mean the repo is clean. Each analys
 
 | Type | What 0 findings means | What to do next |
 | ------------------------- | ------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| `tech-debt-quick`  | Metadata files didn't expose any stale versions. **Inconclusive** -- quick scan only inspects manifests. | Tell the user the result is inconclusive (metadata-only). Offer to run `tech-debt-comprehensive` for a code-level analysis. |
+| `rapid-techdebt-analysis` | Metadata files didn't expose any stale versions. **Inconclusive** -- quick scan only inspects manifests. | Tell the user the result is inconclusive (metadata-only). Offer to run `tech-debt-comprehensive` for a code-level analysis. |
 | `tech-debt-comprehensive` | Bedrock did not surface tech-debt issues. Repo is likely well-maintained, but other dimensions weren't checked. | Offer `security` for CVEs, `agentic-readiness` for AI-readiness, and `modernization-readiness` for modernization opportunities. Mention these are separate scans. |
 | `security` | Security Agent didn't surface CVEs or vulnerable patterns. | Verify the Security Agent is healthy (`atx ct setup security-agent --status`). If healthy, offer `tech-debt-comprehensive` for non-security issues. |
 | `agentic-readiness` | Repo did not show AI-readiness gaps at the framework level. | Offer `modernization-readiness` for cloud/infrastructure modernization or `tech-debt-comprehensive` for general code health. |
@@ -220,12 +220,12 @@ If an analysis returns 0 findings on a repo that's obviously stale (Java 8, Node
 
 `atx ct analysis list` exposes these filters. Pick the narrowest combination the question allows.
 
-| Filter | Where it runs | Allowed values |
-| --------------- | --------------------------------------- | ------------------------------------------------------------------------------------------------------------------ |
-| `--status` | server-side (GSI-backed, fast) | `pending`, `running`, `complete`, `cancelled`, `failed` |
-| `--type` | server-side (GSI-backed, fast) | `tech-debt-quick`, `tech-debt-comprehensive`, `security`, `agentic-readiness`, `modernization-readiness`, `custom` |
-| `--category` | client-side (does not reduce the fetch) | `"Tech Debt"`, `"Security"`, `"Agentic Readiness"` |
-| `--schedule-id` | server-side | a schedule's `sched-` analysisId (from `atx ct schedule list`) — lists that schedule's fired child runs, newest first |
+| Filter | Where it runs | Allowed values |
+| --------------- | --------------------------------------- | -------------------------------------------------------------------------------------------------------------------------- |
+| `--status` | server-side (GSI-backed, fast) | `pending`, `running`, `complete`, `cancelled`, `failed` |
+| `--type` | server-side (GSI-backed, fast) | `rapid-techdebt-analysis`, `tech-debt-comprehensive`, `security`, `agentic-readiness`, `modernization-readiness`, `custom` |
+| `--category` | client-side (does not reduce the fetch) | `"Tech Debt"`, `"Security"`, `"Agentic Readiness"` |
+| `--schedule-id` | server-side | a schedule's `sched-` analysisId (from `atx ct schedule list`) — lists that schedule's fired child runs, newest first |
 
 **Recommended shapes:**
 
@@ -235,7 +235,7 @@ If an analysis returns 0 findings on a repo that's obviously stale (Java 8, Node
 - "What has my nightly schedule run so far?" → `atx ct analysis list --schedule-id <sched-id> --json` (the fired child runs of that schedule; get `<sched-id>` from `atx ct schedule list`)
 - One specific run → `atx ct analysis get --id <id> --json` (point lookup; cheaper than list).
 
-`--category` is a client-side grouping; e.g. `"Tech Debt"` matches both `tech-debt-quick` and `tech-debt-comprehensive`. Use it when the user wants both subtypes together.
+`--category` is a client-side grouping; e.g. `"Tech Debt"` matches both `rapid-techdebt-analysis` and `tech-debt-comprehensive`. Use it when the user wants both subtypes together.
 
 `--schedule-id` is how you inspect a schedule's history: each fire creates one child analysis, and this lists them newest-first. It **cannot** be combined with `--status` or `--type` (the CLI returns `INVALID_INPUT`). To read one fire's findings, take a child's id and run `atx ct findings list --analysis-id <id> --json`.
 

aws-transform/steering/workload-continuous-modernization-discovery.md

@@ -27,8 +27,8 @@ atx ct discovery scan --source <name> --path <new-dir>
 # Scan a GitHub source (use the bare name from `source add --name`)
 atx ct discovery scan --source <name>
 
-# Check scan status
-atx ct discovery status --source <name>
+# List the repos a scan registered
+atx ct repository list --source <name> --json
 ```
 
 ## After discovery completes

aws-transform/steering/workload-continuous-modernization-findings.md

@@ -88,7 +88,7 @@ Filtering at the CLI is materially faster than pulling everything and filtering
 - Per-repo loops when a single `--source` filter would cover the whole batch.
 - Omitting `--status open` when the user only cares about live findings — `dismissed` and `obsolete` pile up over time.
 - Passing `--type` and `--analysis-id` together when `--analysis-id` alone already pins the result set to one run.
-- "Auto-fixable" without a transform name → narrow with `--type tech-debt-quick` first. `tech-debt-quick` findings carry an ATX-transform fix; `security` findings carry a security-agent fix (see the [remediation](workload-continuous-modernization-remediation.md) skill). Findings without a `fix` field may still be remediable — see the [remediation](workload-continuous-modernization-remediation.md) skill's decision tree.
+- "Auto-fixable" without a transform name → narrow with `--type rapid-techdebt-analysis` first. `rapid-techdebt-analysis` findings carry an ATX-transform fix; `security` findings carry a security-agent fix (see the [remediation](workload-continuous-modernization-remediation.md) skill). Findings without a `fix` field may still be remediable — see the [remediation](workload-continuous-modernization-remediation.md) skill's decision tree.
 - `--type` alone or `--type --severity`/`--type --min-severity` (no status, no repo) → add `--status open` to anchor on the live-triage shape.
 - Passing both `--severity` and `--min-severity` in the same call → the CLI rejects this. Pick one.
 - Treating the first page of `atx ct findings list` as the complete set when the response carries a non-empty `nextToken`. Page through with `--next-token <token>` until no `nextToken` remains — otherwise you silently drop findings.

aws-transform/steering/workload-continuous-modernization-reporting.md

@@ -231,7 +231,7 @@ Fields (raw → normalized): `id`, `analysis_type` → `analysisType`, `status`,
 
 Two charts side-by-side:
 1. Bar — severity counts. Use `status === 'open'` only. **Only include severity buckets that have at least one finding** — don't render zero-count columns. Iterate `['high','medium','low']` in that order, filter to non-zero, then plot.
-2. Doughnut — analysis-type split (`quick-scan`, `tech-debt`, `security`, `agentic-readiness`, `custom`, `manual`). Same rule: only include types with at least one finding.
+2. Doughnut — analysis-type split (`rapid-techdebt-analysis`, `tech-debt-comprehensive`, `security`, `agentic-readiness`, `modernization-readiness`, `custom`, `manual`). Same rule: only include types with at least one finding.
 
 **Severity enum is `high | medium | low`. There is no `critical`.** 
 

aws-transform/steering/workload-continuous-modernization-security-agent.md

@@ -115,7 +115,7 @@ Do NOT proceed until status is `configured`.
 Once setup is verified, proceed with the normal analysis flow using `--type security`. The CLI discovers the security agent configuration from CloudFormation at runtime — no manual config steps are needed.
 
 ```bash
-atx ct analysis run --type security --sources <source-name>
+atx ct analysis run --type security --source <source-name>
 ```
 
 The executor IAM policy required for runtime is documented in `AWSTransformSecurityAgentExecutorAccess.json` (included with this skill).