al-validate-breaking-changes

What problem does it solve? Before merging an AL/Business Central feature, you need to know whether it breaks a previously released public API — something the compile-time AppSourceCop pass cannot fully simulate. This Skill runs the AppSource-style install/upgrade validation against the provisioned baseline release and records the verdict on the feature's final gate task. ## Core Features & Use Cases - Breaking-change gate execution: Runs validate-breaking-changes.ps1 (per-country install/upgrade via Run-AlValidation) against the cached baseline from /al-provision, delegated to a subagent to keep the main session clean. - Exit-code-driven status flip: Maps exit codes to task status — 0 to done, 3 (breaking change detected) or 4/other failures to blocked — editing only the status: frontmatter line. - Human-in-the-loop on breaks: A detected break is treated as an intent decision (intended major bump vs accidental schema change) routed to /al-steer, never auto-fixed or auto-accepted. - Use Case: As the last task of an AL feature, after the per-feature code review passes clean, run this gate to confirm the post-review bytes do not break the released public API before merge. ## Quick Start Run the breaking-change validation task for my current AL feature and update its status based on the result.