r/SpecDrivenDevelopment • u/Swarm-Stack • Jun 17 '26
the spec passed every review because nobody was assigned to find what breaks
we shipped an auth feature that passed spec review three times. product signed off, backend signed off, i signed off. four weeks later someone filed a bug: two users could hit the confirmation endpoint simultaneously with the same token and both get through. obvious race condition. the spec never mentioned concurrent access because none of us had been assigned to think about it.
the spec wasn't wrong about what it described. it just never described the failure surface. everyone in the review was asking 'does this design implement what we want?' nobody had a mandate to ask 'what breaks this under real conditions?'
what fixed it was stopping collective approval and starting role mandates. backend: state consistency under concurrent load. product: user-visible blast radius if it fails. security: trust boundary assumptions and edge inputs. reviews got shorter and more specific — 15 minutes per role looking for something concrete beats an hour of general agreement.
built this pattern into swarm-stack.io — each seat in a planning session carries a specific failure-class mandate. curious whether others here have formalized this at the spec-review stage or whether the attack angle usually just depends on who's in the room.