spec-reliability-implementation — a spec becomes a service that provably behaves like the spec

⚠️ Critical Constraints

• The spec is the source of truth, not the code. Every accepted behavior must trace to a spec clause. Why: code that "works" but diverges from the spec is a silent breach — the bug ships because nothing checks it against intent.

• Acceptance examples come BEFORE implementation. Write the executable examples (Given/When/Then) from the spec first, watch them fail, then make them pass. Why: examples written after the code only re-encode the code's behavior, so they can never catch a spec mismatch.

  WRONG: implement endpoint → write a test that asserts whatever it returns
  CORRECT: write Then "POST /orders twice with same key yields ONE order" → run (fails) → implement idempotency → run (passes)