Spec→code conformance before merge: shared report schema + deterministic gate consumer

[PascalThuet]

The March newsletter names a roadmap direction I care about: CI/CD integration that incorporates Spec Kit verification into PR workflows and fails builds when specs are out of alignment. April also calls spec-level drift detection an open area.

I looked for an existing maintainer-led design thread for that exact mechanism and did not find one. I did find a cluster of adjacent community threads:

• Need for spec-kit self-assessment command to review and fix diverging non-conformant code #471: self-assessment for non-conformant code — the closest prior idea, where
  Quratulain-bilal floats an opt-in, deterministic /speckit.trace (stable IDs + coverage
  matrix). Open, with no visible maintainer response yet.
• /audit Command for Post-Implementation Verification #535: /audit for post-implementation verification
• /speckit.verify - browser/cli testing framework & execution #1662: /speckit.verify for browser/CLI testing
• Idea: SpecLang — make spec.md the source of truth, not a generator input #2368: SpecLang / spec.md as source of truth
• The /implement command allows for deviations from the plan leading to unpredictable results #464: agents diverging from plan/spec during implementation (older)
• Feature: /speckit.reconcile — close post‑implementation gaps by asking clarifying questions, then amending spec.md, plan.md, and tasks.md #1063: Reconcile, now delivered as a community extension

There are also strong community extensions already doing useful work here: CI Guard (compliance report, gate config, drift check, badge), Verify (post-implementation read-only verification), plus Spec Sync, Reconcile, and Architecture Guard. So I do not think the gap is "no one has built a verifier."

The narrower gap I want to discuss is the merge gate contract.

Today, the closest tools generate useful conformance signals through agent prompts. CI Guard, for example, instructs the agent to be deterministic and to recommend an exit code, but the verdict is still produced by an LLM interpreting a Markdown command. That is fine for analysis, but weak as the final merge gate.

What I think is missing is a small shared primitive:

1. A versioned conformance-report schema: requirement / acceptance criterion /
   task → satisfied, missing, deviated, with evidence refs and deviation
   notes.

2. A deterministic gate consumer: no LLM, just:

   conformance-report.json + gate-config.yml => exit 0 / exit 1
   

This does not claim the report is magically correct. Report generation can remain agentic and extension-driven. The point is only to make the final PR decision reproducible: same report + same config = same exit code.

This seems aligned with the roadmap item while staying smaller than "add a native verifier command." Existing extensions could keep competing on report generation quality, while converging on one report shape and one dumb gate decision.

Concretely, this dovetails with #471: a stable-ID + coverage-matrix generator like the /speckit.trace floated there would emit exactly the report this gate consumes — two halves of one idea rather than competing commands. It would be better to align on a shared report shape than to create parallel formats.

Before building anything large, I would like maintainer guidance:

1. Does a deterministic, agent-independent conformance gate decision fit the
   project direction, given the CI/CD roadmap item?
2. Would maintainers want a shared conformance-report schema to converge in core
   eventually, or should this stay fully extension-owned?
3. Is the right path to prototype schema + consumer as an extension first, then
   revisit core adoption if the community finds it useful?

Happy to prototype this extension-first and coordinate with CI Guard / Verify authors if the direction makes sense.

(Posting with AI assistance, disclosed per CONTRIBUTING.md.)

[mnriem]

Would love to see an extension/preset/workflow first, yes. Then we can see how it works and how it is adopted :)