How about having a QA person take a look at the stories? If you want a perspective that is “how can this break?” that is the perspective of QA. The developer looks at the solution to the story to get the story to work. Even with a “tiny seed of an accidental asshole” developers are looking to get the story done as written. Very rarely do they delve in to the negative case scenario. Good QA people tend to be more holistic in their view of functionality as it may affect something unintentionally.
My experience of sitting in a grooming meeting and talking about the negative cases or what are perceived to be corner cases is that people (dev, product, et al) just want to move on and not discuss those issues. Product wants the stories pointed and devs are not engaged until they are assigned the story (which for us happens in sprint planning).
We all know the cost benefits of finding issues early on and QA people seem to be on the forefront saving money in that aspect but it cannot possibly be measured which makes the QA person an annoyance rather than a contributing team member.