Best practices for reaching spec agreement — does the spec become the single source of truth?

[managerialsolution]

I'd like to understand how teams are approaching spec agreement in a spec-driven development (SDD) workflow, and share how we currently do it. For context, we're a team of 7 developers.
Our current approach:
In our team, the tech lead authors the specification and circulates it to developers and other leads for review. The output of that review is a well-agreed set of When/Then scenarios that everyone signs off on.
Once the spec is agreed by all parties — Product team, application developers, and leads — we run opsx: apply to generate the code. At that point, the review focus shifts away from the code and onto the spec itself.
We're also experimenting with generating HTML from spec.md to review architecture and design decisions in a more readable format.

What I'm trying to understand:
What are the best practices for getting genuine agreement on a spec across roles (PO, devs, leads) before code generation?
Once you adopt this flow, does the focus shift entirely to the spec as the single source of truth, or do teams still review the generated code in practice?
How do you prevent spec-drift — when generated code gets manually tweaked, how do you ensure those changes flow back into the spec rather than the spec and code silently diverging over time? This feels like the biggest risk of treating the spec as the sole source of truth, and I'd love to hear how others handle it.

Interested in how others structure the review/sign-off step, and whether "spec as single source of truth" holds up in real projects over time.

[alesky78]

I think OpenSpec does not replace code review,
it changes where the main agreement happens.

Your approach with shared When/Then scenarios is very close to what I would consider a good practice.
The important part is that Product, developers, and leads agree on the expected behavior before implementation starts. The spec becomes the place where ambiguity is removed.

After /opsx:apply, code review is still important. The question simply changes
from: "Did we build what was requested?"
to: "Did we correctly implement what we agreed on?"

This is where /opsx:verify is useful: it helps check that the implementation and the change artifacts are still aligned.

Regarding spec drift, I don't think the solution is to completely prevent manual code changes. Real projects need iteration. The important part is reconciliation:

If the requirement changed → update the spec/design.
If the code drifted → update the code.

The dangerous state is when code and spec evolve independently.

This is also where /opsx:update fits: it allows the change artifacts to evolve together with the implementation instead of becoming outdated documentation.

So I would not see the spec as the single source of truth for everything. I would see it as the source of truth for intent and expected behavior, while the code remains the source of truth for the actual implementation.

The workflow is not: Spec → Code → Done
but rather: Spec → Code → Verify → Update if needed → Archive

The biggest benefit of SDD is moving the discussion about correctness earlier,
before code exists, while still keeping normal engineering practices like code review.

note: new doc page for reconciliation
https://github.com/Fission-AI/OpenSpec/blob/main/docs/editing-changes.md