Phase D of a WinForms-to-Avalonia migration: build the Avalonia UI shell with composition, MVVM state and commands, responsive XAML, accessibility, localization boundaries, and behavior-focused unit/Headless tests. Use only when an explicit migration is ready to port Forms or when the orchestrator routes here. Prefer this over control-by-control ports.
Phase A of a WinForms-to-Avalonia migration: inventory the legacy application, split responsibilities, capture command and state contracts, build a coverage matrix, and define acceptance evidence without implementing Avalonia UI. Use only in an explicit WinForms-to- Avalonia migration when behavior is undocumented or the orchestrator routes here. Generated artifacts must use the current repository's real paths, terminology, and capabilities.
Phase B of a WinForms-to-Avalonia migration: extract UI-independent application behavior, state rules, use cases, and boundary contracts with TDD and no WinForms/Avalonia references. Use only when an explicit migration still has business behavior in Forms or UI helpers, or when the orchestrator routes here. Do not build Avalonia XAML in this phase.
Phase G of a WinForms-to-Avalonia migration: decompose oversized UI state and orchestration, harden asynchronous workflows and external boundaries, preserve composition lifetimes, keep Headless tests process-isolated, and update ownership documentation. Use only when an explicit migration has post-port structural or resilience debt, or when the orchestrator routes here. Baseline input security belongs in the phase that introduces the boundary, not only here.
Phase E of a WinForms-to-Avalonia migration: verify behavioral parity against Phase A contracts, record intentional differences, validate supported environments and packaging, and make evidence-based legacy cutover decisions. Use only for an explicit migration when comparing the legacy and Avalonia implementations or when the orchestrator routes here. Do not delete legacy without the cutover checklist and explicit authorization.
Phase C of a WinForms-to-Avalonia migration: implement platform and infrastructure adapters for dependencies discovered in Phase A/B, such as persistence, process execution, dialogs, notifications, or environment capabilities. Use only in an explicit migration when such dependencies leak into Forms/core or when the orchestrator routes here. Do not invent adapters for capabilities the product does not have, and do not implement main-window XAML.
Phase F of a WinForms-to-Avalonia migration: evolve the Avalonia trunk after cutover without reintroducing WinForms coupling or bypassing established layers. Use only when an explicit migration has an active Avalonia trunk and a concrete product backlog, or when the orchestrator routes here. Select work from repository evidence; do not assume particular entry points, integrations, settings, or extension mechanisms exist.
Orchestrate a phased WinForms-to-Avalonia migration: behavior contracts, UI-independent application logic, platform adapters, MVVM shell, parity/cutover, evolution, and hardening. Use when the request explicitly involves moving a WinForms or .NET Framework desktop UI to Avalonia, or continuing that migration. Do not trigger for unrelated migrations, rewrites, ViewModel refactors, settings work, or command-line work without WinForms-to-Avalonia context. Load this orchestrator before one matching phase skill.