UCT Roadmap

Help developers plan Magento upgrades with compatibility findings they can trust, a clear understanding of what was checked, and less manual investigation.

Assessment date: 17 October 2026. Based on eight currently open UCT-related issues, their discussions, and the current development changelog. Priorities below are a proposed assessment, not existing GitHub priority labels or release commitments. No issues were closed or relabelled during this review.

Importance assessment

Prioritize problems that undermine scan availability or confidence before expanding the types of checks. Consider developer impact, evidence quality, workarounds, and dependencies. The open reports below date from 2022–2023; none was reproduced on a current IDE as part of this assessment. Age alone does not establish that a defect still exists.

P1 — first: trustworthy results and a usable analysis workflow. P2 — next: broader practical coverage and control. P3 — research: promising extensions needing concrete examples and scope validation.

Priority	Issue	Why it matters	Evidence and next decision
P1	#1219 — Target-version inspection data	Developers cannot rely on upgrade checks without analysis data for the version they intend to adopt. This underpins other checks.	The original request concerns 2.4.5, with discussion also asking for 2.4.6. Version discovery and custom target selection have since evolved. Audit actual analysis coverage before treating the old request as still missing; a selectable release is not proof that every check supports it.
P1	#1246 — Non-API class findings	Large volumes of poorly explained findings can obscure actionable upgrade problems and reduce trust.	Concrete class examples are provided, but they do not prove false positives. Recheck scope, target-version data, and API status; distinguish a genuine non-API usage risk from a confirmed incompatibility.
P1 triage	#1220 — Inspection exception during method resolution	An inspection failure can interrupt analysis and leave results incomplete.	Historical Windows/WSL stack trace involving an image file and IDE indexing. Reproduce on supported IDEs and determine whether the cause is plugin logic or platform/index state. Do not assume every indexing failure is a UCT defect.
P1	#1101 — Missing live findings in vendor templates	A developer can see a report finding but no corresponding warning while editing the affected third-party template.	The discussion narrows the report: PHTML worked in app/code and app/design; vendor modules were suspected. Reproduce this specific scope difference rather than claiming all PHTML is unsupported.
P2	#1039 — Exclude multiple folders	Developers need focused scans without repeatedly processing irrelevant directories.	The issue is a title-level request with a template body. Validate representative scan scopes and existing controls, then define predictable exclusion behavior.
P2, high potential impact	#1042 — Changed method and constructor arguments	Argument changes can break customizations after an upgrade even when the referenced method still exists.	The request lacks concrete examples. Establish real version-pair cases and distinguish target-version compatibility checks from inspections already provided by PhpStorm. Requires reliable target data.
P3	#1040 — GraphQL schema compatibility	Schema changes can affect custom APIs and storefront integrations.	Title-level request. Define upgrade-specific failures and compare existing GraphQL validation before committing to implementation. Foundational for request validation.
P3	#1041 — GraphQL calls from JavaScript	Storefront requests may become incompatible with a target schema.	Title-level request. Validate real queries and fragments, source locations, and dynamic-query limitations. Depends on a trustworthy target schema and the scope established for #1040.

P1 indicates importance, not a claim of a currently confirmed defect. Reproduction may move an issue to maintenance, documentation, upstream follow-up, or closure review. No evidence reviewed establishes an emergency P0 issue.

First: establish a trustworthy baseline

• Reproduce the historical reports on supported IDE/plugin versions and record project setup, analysis mode, current version, target version, and selected scope.
• Audit which target versions and checks have usable compatibility data; clearly distinguish unavailable or incomplete analysis from a clean result. Reconcile the old target-version request with current capabilities. #1219
• Review the reported non-API examples and explain whether each finding represents unsupported API usage, deprecation, removal, or another compatibility risk. Correct inaccurate findings without suppressing legitimate warnings. #1246
• Investigate the inspection exception and provide a reproducible fix or documented platform follow-up. Keep incomplete analysis visible to the developer. #1220
• Make findings consistent for explicitly included third-party PHTML templates across the relevant live and batch workflows, or clearly explain differences in scope or analysis capability. #1101

Acceptance: known examples produce expected findings, unsupported analysis is explicit, and developers can understand why a file or target was not checked. Confirmed defects have regression cases; resolved historical reports have closure evidence for maintainer review.

Next: make upgrade checks focused and more complete

• Let developers exclude multiple irrelevant folders and see the effective scan scope. Preserve settings and explain how exclusions apply to each supported analysis mode. #1039
• Validate method and constructor compatibility against the chosen target using real upgrade examples: changed argument types, required argument counts, and ordering where it affects compatibility. Report the affected call or declaration with a clear explanation. #1042
• Test both breaking and compatible changes so additional checks do not overwhelm users with misleading warnings.

Acceptance: exclusions reliably omit the intended files without hiding the remaining scope; signature checks detect demonstrated target-version breakages while keeping valid customizations clear of false alarms.

Later: validate GraphQL upgrade workflows

• Collect concrete schema-change examples and identify the gap between existing GraphQL assistance and target-version upgrade checks. #1040
• Prototype schema compatibility checks before extending validation to JavaScript queries and fragments. #1040, #1041
• Show findings at useful source locations and explicitly identify dynamic requests or missing schema information that cannot be evaluated. #1041
• Proceed to implementation only when representative storefront workflows demonstrate a benefit beyond existing validation.

Acceptance: a known breaking schema change is explained at the affected schema or request location, a compatible request remains valid, and unresolved dynamic behavior is not presented as checked successfully.

Preserve improvements already delivered

#2512 — PHP memory exhaustion during external UCT runs is closed as completed. The 2026.3.3 changelog records the PHP memory-limit override. Keep it covered by regression checks; do not plan it again as a new feature.

The 2026.3.3 release also added compatibility analysis through MCP, including target discovery and background scans. Future UCT improvements should keep equivalent supported checks understandable across the IDE and MCP workflows rather than introduce a separate definition of compatibility.

Scope and delivery

The plugin's built-in inspections and the externally executed Adobe UCT are distinct analysis paths. Confirm which path each report concerns, and document their capabilities and limitations separately. Do not promise identical findings from different analyzers.

Deliver in small, issue-linked increments with reproducible before/after examples, regression coverage, and end-user documentation. Reassess priority when current evidence changes. This roadmap contains no delivery-date or effort commitments.

Current changelog · 2026.3.3 release · All future work