plan

Plan Stage

Analyzes the project deeply and writes a single migration plan for approval. The migration goal comes from the prompt. Does NOT modify any source files — planning only.

Inputs

• .konveyor/analysis.json — Kantra rule violations and patterns, if present

---

Phase 1 — Analyze

1a. Read Prior Stage Outputs (if present)

1. If .konveyor/analysis.json exists, read it for rule violations and patterns

If it doesn't exist, derive the source stack and target directly from the prompt and the code.

1b. Understand the Project Architecture

Read the build manifest and walk the source layout to understand the project. Do this by reading files — do not build or execute the project.

1. Build manifest (pom.xml, build.gradle, package.json, *.csproj, etc.): dependencies, modules/sub-projects, plugins, packaging type.
2. Directory layout and layers: identify how the code separates into layers — data models/entities, services/business logic, controllers/API, persistence, configuration.
3. Dependency flow: from imports and package structure, work out who depends on what (typically Models → Services → Controllers).
4. High-risk abstractions: files that many others import, or that carry the most framework-specific patterns. Mark these as COMPLEX in the plan — changes here ripple across many files.

1c. Match Patterns to Files

Use the target's migration patterns to identify which files need migration. Check each file's imports, declarations, and configuration against the target's transformation rules to classify it:

• Simple (mechanical import or declaration replacement only)
• Complex (structural changes needed)
• Delete (file will be removed)
• Create (new file needed)

Use the analysis results as well: if .konveyor/analysis.json is present, each incident pins a file, line, and message for a required change — cross-check your classification against it and make sure every flagged incident maps to a step.