[Proposal] /opsx:validate command to check code against the living specs

[gareth-robinson]

The OpenSpec codebase currently has /opsx:verify command that can be used to check implementation against change artifacts (the ones in openspec/changes/<name>/).
However, there's no equivalent for validating the current implementation against the main specs in openspec/specs/. This seems like a gap; why keep 'source of truth' specs when the toolset doesn't provide tools to make direct use of them?

As an example. The 'Contributing' section of the 'README.md' in this repo says for example "Small fixes — Bug fixes, typo corrections, and minor improvements can be submitted directly as PRs." - it seems probable that in any project there will be small changes and adjustments where raising an openspec change is overkill. In that case it would be the living spec where any change could be directly documented (would be on the developers then to decide how or if they want to document the deviation from the archived changes)

This suggestion is for a command like /opsx:validate <spec-name> so users would have both tools:

• /opsx:verify for checking changes
• /opxs:validate for checking current specs
  Given that the main spec does not have design or tasks, this command would check correctness only, not completeness or coherence, so would be a less detailed report than /opsx:verify.

[gareth-robinson]

The Contributing section of the README.md says to make a proposal before implementation: but if it helps illustrate the idea I have a change here: main...gareth-robinson:OpenSpec:main

[TabishB]

@gareth-robinson When and how often do you validate code against existing specs? (trying to figure out frequency of use here)

I'm not opposed to this, it can most likely end up as an optional skill. Just unsure how often people would use it. I think ideally its the kind of thing that would need some automation behind it to be useful. e.g running it in CI every 5 commits to see if the new code introduced any drift etc? WDYT?

[gareth-robinson]

Hi @TabishB - its a hypothetical; I think that there may always be small dev changes to a project where writing a new change spec might seem like overkill; say someone wants to change the default pagination size in some API from 10 items to 20 items, then that might just be altering a constant and a unit test in some code, and updating the main spec to say the default is now 20. The 'philosophy' section of the README.md also mentions brownfield as well as greenfield development, so while adoption is underway there could still be development outside of OpenSpec and validate would then be like a regression test to make sure other changes haven't affected the bits that the specs are meant to cover.

Perhaps it does have only limited use cases. I guess you could make a counterargument that if it's overkill to use a change spec for everything then maybe its also overkill for OpenSpec to provide skills outside of that flow? i.e. do we consider main specs as an editable entity on their own outside of the OpenSpec flow?