feat(aws-transform): publish mainframe-reimagine suite, .NET NextSteps ingestion, and continuous-modernization updates

[nikhil1]

Summary

Publishes the AWS Transform Agent Plugin release v1.3.0 (from internal ATXKiroPower, tag skill-1.3.0).

mainframe-reimagine — first-time publish

Adds the full mainframe-reimagine capability that was previously present in the Kiro Power (kirodotdev/powers) but never published here: mainframe-reimagine.md + mainframe-reimagine-{modern-traceability,analysis,ddd,specgen,verify}.md, plus mainframe.md routing so references resolve.

.NET

• Auto-download artifacts and ingest NextSteps.md at completion (mirrors kirodotdev/powers#162, which shipped this to the Power only).

continuous-modernization

• 250-repo cap with splitting
• Version-agnostic pagination + nextToken handling
• Background logs written to /tmp
• Blocking --wait semantics
• Remediation-cap wording fix

Version

Bumped to 1.3.0 in .claude-plugin/plugin.json, .codex-plugin/plugin.json, and the aws-transform entry in .claude-plugin/marketplace.json (catalog metadata.version untouched).

Validation

dprint check and markdownlint-cli2 both clean against the repo's pinned configs.

---

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of the project license.

cc @alkrok @scoschre

[scottschreckengaust]

Code review

Repo tooling is green (lint:cross-refs, lint:manifests, fmt:check, lint:md all clean; version bump 1.2.0→1.3.0 consistent across the three manifests, and .agents/plugins/marketplace.json correctly carries no version). The findings below are in the prose/instruction content of the new mainframe-reimagine suite — each would cause an agent following the pipeline to fail or misbehave at runtime.

Found 4 issues:

1. Phase 4 references verify-traceability.py, but the script does not exist in the repo and no phase generates or downloads it. Phase 4 is described as a "purely mechanical, script-based check," and the router hard-depends on its traceability-dashboard.html output — so as written the pipeline stalls here.

agent-plugins/plugins/aws-transform/skills/aws-transform/references/mainframe-reimagine-verify.md

Lines 83 to 92 in d4d0c19

	The verification script is located at `verify-traceability.py`. Run it with the appropriate paths:
	```bash
	python3 verify-traceability.py \
	--inputs-dir inputs/spec \
	--specs-dir outputs/microservices \
	--output traceability-dashboard.html
	```

2. Broken code-fence nesting swallows the Step 6 and Step 7 headings into a code block. The 4-backtick fences in this section pair as (247→264), (282→319), (323→363), so ### Step 6: Define Event Publishing and ### Step 7: Define Service Communication render inside code blocks. markdownlint passes because the fences are balanced, but they're misplaced.

agent-plugins/plugins/aws-transform/skills/aws-transform/references/mainframe-reimagine-specgen.md

Lines 281 to 286 in d4d0c19

	````
	### Step 6: Define Event Publishing
	Map domain events from the DDD analysis that originate from this bounded context:

3. --inputs-dir default (inputs/spec) contradicts the workspace layout the router builds. The router unzips specs to spec/ at the workspace root, and every other phase reads spec/<FunctionName>/. No inputs/ directory is ever created, so the documented command finds no inputs. Should be spec (or ./spec).

agent-plugins/plugins/aws-transform/skills/aws-transform/references/mainframe-reimagine-verify.md

Lines 95 to 98 in d4d0c19

	| Parameter | Default | Description |
	| -------------- | ----------------------------- | ------------------------------------------------------ |
	| `--inputs-dir` | `inputs/spec` | Path to the business function input directory |
	| `--specs-dir` | `outputs/microservices` | Path to the generated microservice specification files |

4. Spec-header key mismatch between the writer (Phase 3) and the reader (Phase 5). specgen emits > **Source**: ... | **Source Function**: <FunctionName> (singular key, pipe-delimited), but modern-traceability parses a standalone > **Source Functions**: <comma-list> line to locate the spec/<FunctionName>/traceability.yaml files. With the writer/reader out of sync, the legacy_rule_ids back-fill silently fails.

agent-plugins/plugins/aws-transform/skills/aws-transform/references/mainframe-reimagine-specgen.md

Lines 477 to 479 in d4d0c19

	> **Source**: <BC-N Context Name> | **Mapping**: <1:1 or 1:N> | **Source Function**: <FunctionName>
	> **Validates**: <summary of requirement ranges covered>

agent-plugins/plugins/aws-transform/skills/aws-transform/references/mainframe-reimagine-modern-traceability.md

Lines 85 to 89 in d4d0c19

	```
	> **Source Functions**: BatchDataProcessing-AccountProcessing, OnlineTransactionProcessing-AccountManagement
	```
	This determines which `spec/<FunctionName>/traceability.yaml` files contain the legacy rule hashes that back-fill the `legacy_rule_ids` field in `traceability-modern.yaml`.

Additional notes (lower confidence, not blocking):

• remediation create --wait contradiction. This PR adds --wait to atx ct remediation create here, but unchanged sibling files in the same skill (continuous-modernization-ec2-execution.md, -batch-execution.md, -schedule.md) assert that remediation create has no --wait flag. Reconcile them so the agent doesn't get conflicting guidance. The analogous analysis run --wait addition is consistent with those files.

agent-plugins/plugins/aws-transform/skills/aws-transform/references/continuous-modernization-remediation.md

Lines 69 to 72 in d4d0c19

	`atx ct remediation create` returns immediately by default with a remediation ID. With `--wait` it blocks until the remediation completes — and applying transforms across repos can take a long time. Prefer `--wait` so you can act on the result in the same step.
	**`--wait` is version-gated** — it exists only in newer CLI versions. Confirm support via `atx ct remediation create --help` (or `atx ct --version`) before relying on it; if it isn't listed, run without `--wait` and do not invent the flag. If a run fails with an unknown-option error for `--wait`, re-run without it.

• --wait fallback is broad. "If a run fails with an unknown-option error for --wait, re-run without it" could mask an unrelated failure (auth, INVALID_INPUT, 250-repo rejection) as a missing-flag error, and blindly re-running a side-effecting create/run risks a double-submit. Consider constraining the retry to an error that explicitly names --wait as unrecognized, and confirming the first attempt returned no ID before retrying.

🤖 Generated with Claude Code

_{- If this code review was useful, please react with 👍. Otherwise, react with 👎.}

[scottschreckengaust]

recommendations added in PR comment

[nikhil1]

@scottschreckengaust I included the review comments by pulling in Ashe's fixes from internal repo.

[scottschreckengaust]

Follow-up review — verified against e5e336c

Re-checked all six items from my earlier review against the current head, and ran a second pass over the new verify-traceability.py. Repo tooling and CI are green; version bump 1.3.0 is consistent across .claude-plugin/plugin.json, .codex-plugin/plugin.json, and the aws-transform entry in .claude-plugin/marketplace.json (catalog metadata.version correctly untouched). Cross-reference links and TOC anchors resolve.

Thanks for pulling in Ashe's fixes — 3 of the 4 blocking items are genuinely resolved. Requesting changes on the two that aren't.

✅ Resolved

1. verify-traceability.py now exists at plugins/aws-transform/skills/aws-transform/scripts/verify-traceability.py, self-identifies as the Phase 4 tool, and produces traceability-dashboard.html (--output default at :647) — the router's dependency is now satisfiable.
2. Code-fence nesting in specgen.md — fixed by switching the outer example blocks to 4-backtick fences (247→264, 300→319). ### Step 6 (:282) and ### Step 7 (:323) now render as real headings, outside all fences.
3. --inputs-dir documented default in mainframe-reimagine-verify.md:97 is now spec, matching the spec/ layout the router unzips into. (See residual note below.)

❌ Still open — blocking

Item 4 — writer/reader spec-header key mismatch is NOT resolved.

• Writer (Phase 3), mainframe-reimagine-specgen.md:477:
  > **Source**: <BC-N Context Name> | **Mapping**: <1:1 or 1:N> | **Source Function**: <FunctionName> — singular Source Function.
• Reader (Phase 5), mainframe-reimagine-modern-traceability.md:86 (also :271-272, :391):
  > **Source Functions**: ... — plural Source Functions.

The pipe-delimited-vs-standalone-line concern is now aligned, but the key name still differs (singular vs plural), so Phase 5's match on **Source Functions** won't find the header Phase 3 wrote, and the legacy_rule_ids back-fill silently fails. Pick one key name and use it in both files.

Items 5 & 6 — remediation create --wait guidance is still self-contradictory.

• continuous-modernization-remediation.md:69 now says --wait is supported and preferred, but three unchanged sibling files still assert it does not exist:
  • continuous-modernization-batch-execution.md:782 — "atx ct remediation create does NOT support --wait, so we poll…"
  • continuous-modernization-ec2-execution.md:458 — "# Poll until terminal (atx ct remediation create has no --wait flag)"
  • continuous-modernization-schedule.md:821 — "# Poll every 30s until terminal status (atx ct remediation create does not support --wait)"
    An agent gets opposite instructions depending on which file it reads. (analysis run --wait is fine — no sibling contradicts it.)
• The broad-fallback wording (remediation.md:71) is unchanged: "If a run fails with an unknown-option error for --wait, re-run without it" still (a) triggers on any unknown-option error, not one that names --wait, and (b) blindly re-runs a side-effecting create without checking the first attempt returned no ID — a double-submit risk.

🔧 New findings from re-review (non-blocking)

• verify-traceability.py:636 still defaults --inputs-dir to inputs/spec — the exact wrong path item 3 was about. It only works because the documented commands always pass --inputs-dir spec explicitly; running the bare command finds nothing. Suggest changing the script default to spec for consistency.
• No doc tells the agent the script lives under scripts/. mainframe-reimagine-verify.md invokes python3 verify-traceability.py as if from cwd, but the file is in scripts/. Add the path (e.g. scripts/verify-traceability.py) so Phase 4 can actually locate it.
• Malformed traceability.yaml aborts the whole Phase 4 run. verify-traceability.py:56-57 calls yaml.safe_load with no error handling; one bad file raises an unhandled ScannerError, exits 1, and writes no dashboard. A try/except that skips-and-warns would make the mechanical check robust.
• rule_text_summary (:70) isn't in the documented rule schema (mainframe-reimagine-analysis.md:113 lists rule_id, program, req_ids, traceability_lines). If the generated YAML lacks that key, the dashboard "Rule Name" column silently renders blank. Reconcile the field name.

nit

• mainframe-reimagine.md:10 TOC text "Download and Create Workspace" vs heading "Download & Create Workspace" (:43). The anchor still resolves; only the visible text differs.

Happy to re-approve once item 4 and the --wait contradiction are addressed — the rest are polish.

[nikhil1]

@scottschreckengaust please feel free to merge the PR, Issue 4 SME said its not a problem. Issues 5/6 have been addressed. Further comments we can address as followups.

[scottschreckengaust]

LGTM