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.
The English summary is being prepared. Showing the original description.
See how to installReview the instructions the agent will receive before you install.
Prove the Avalonia line is the maintenance trunk, document gaps, then freeze or delete legacy only with evidence.
Read acceptance to build repository-specific scenarios, legacy diff to record evidence, and cutover checklist before freezing or deleting legacy code.
| Feature | New status | Diff / gap | Impact | Decision (fix/defer/retire) |
Populate the matrix from Phase A. Cover every user command, state transition, external effect, failure/recovery path, accessibility contract, supported environment, and deployment path that the product actually has.
Run solution and layer-focused tests; record commands. Sequential multi-project runs if needed.
For large multi-module parity audits, use independent read-only sub-agents per module so conclusions do not pollute one context.
Run the Phase A acceptance scenarios against both implementations where possible. Include startup/lifecycle, primary and secondary workflows, invalid input, cancellation, dependency failure, stale-state prevention, accessibility, and recovery.
If still WinForms-shaped (Refresh, no composition root), file and fix high-severity items.
For each supported target, verify build, publish, install/launch, upgrade or replacement policy, runtime dependencies, assets, licenses, and rollback/recovery expectations.
src“Main path works” is not enough when any required capability or environment remains unverified.
Per capability: implementation status plus automated/manual evidence. Do not mark done when only empty entry points exist. Treat missing untrusted-input bounds, durable persistence, or supported-environment smoke evidence as cutover blockers unless explicitly waived.
First migration done ≠ product complete. Continue with:
wfa-post-port-evolve for product upgradeswfa-harden-decompose for structure/security debtNo reviews yet. Tell others what you thought.
No login needed. Share how it worked for you, ask a question, or note where it did not run.
No comments yet. Be the first to write one.
Implement tasks from an OpenSpec change. Use when the user wants to start implementing, continue implementation, or work through tasks.
The English summary is being prepared. Showing the original description.
Archive a completed change in the experimental workflow. Use when the user wants to finalize and archive a change after implementation is complete.
The English summary is being prepared. Showing the original description.
Archive multiple completed changes at once. Use when archiving several parallel changes.
The English summary is being prepared. Showing the original description.
Continue working on an OpenSpec change by creating the next artifact. Use when the user wants to progress their change, create the next artifact, or continue their workflow.
The English summary is being prepared. Showing the original description.
Enter explore mode - a thinking partner for exploring ideas, investigating problems, and clarifying requirements. Use when the user wants to think through something before or during a change.
The English summary is being prepared. Showing the original description.
Fast-forward through OpenSpec artifact creation. Use when the user wants to quickly create all artifacts needed for implementation without stepping through each one individually.
The English summary is being prepared. Showing the original description.