| name | wfa-parity-verify |
| description | 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 E — Parity verification and cutover
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.
Workflow
1. Capability matrix
| 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.
2. Automated verification
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.
3. Acceptance checklist
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.
4. Modernization pass
If still WinForms-shaped (Refresh, no composition root), file and fix high-severity items.
5. Packaging
For each supported target, verify build, publish, install/launch, upgrade or replacement policy,
runtime dependencies, assets, licenses, and rollback/recovery expectations.
6. Cutover stages
- Trunk switch — all new work on Avalonia/
src
- Legacy freeze — reference only
- Gap burn-down or waivers
- Physical delete only after checklist
“Main path works” is not enough when any required capability or environment remains unverified.
7. Spec verification method
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.
Deliverables
After E
First migration done ≠ product complete. Continue with:
wfa-post-port-evolve for product upgradeswfa-harden-decompose for structure/security debt
