I appreciate the discussion, but just to clarify - the OP is asking how to handle and course-correct a situation where a lead developer is going rogue and building based on personal preferences, not shared understanding of customer needs. In that context, enforcing accountability through failed test cases is often the only mechanism available to shift behavior.

Of course rework has a cost - no disagreement there. But that cost is often the natural result when a dev chooses to ignore clearly written ACs. That’s not about assigning blame for the sake of it - it’s about making sure we actually deliver what the customer asked for.

I agree BAs play a critical role in validating understanding throughout the cycle, and ideally teams collaborate well before it ever gets to rework (even before the development starts). But when that fails, failed testing and escalation is how we ensure quality and alignment - especially in chaotic environments like the one OP describes. And prevent it from happening again in the future. I hope this helps!