wfa-parity-verify

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

1. Trunk switch — all new work on Avalonia/src
2. Legacy freeze — reference only
3. Gap burn-down or waivers
4. 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

• Parity/diff report with decisions
• Test results summary
• Acceptance notes
• Packaging note
• Cutover checklist or dated deferrals

After E

First migration done ≠ product complete. Continue with:

• wfa-post-port-evolve for product upgrades
• wfa-harden-decompose for structure/security debt