When building an agile story and you're producing the what and why having or producing elaborate conditions of success is a fail.
If you're what and why are constructed properly and completely than the user knows exactly what the expectation is.
"I need a widget X which perform some task Y. "
If the conditions of success are the same as the requirements then what would be the point? And they always are!
Conditions of success that suggest 'don't break anything else'are obvious and redundant.
If the story is meant to be formatted and framed in the form of some sort of BBD or spec so that it might possibly be consumed by a test framework then the requirements should be formatted thusly.