Replies: 1 comment
-
|
Hello, isn't that the purpose of OpenSpec to maintain over the time the capabilities definitions ? (I'm new to OpenSpec and have done only a few evolutions but I can see how it keeps code and specs synced). |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
In spec-driven development (SDD), particularly with frameworks like OpenSpec, the spec is treated as the source of truth. The prescribed workflow commits all spec artifacts directly to the repository alongside the implementation.
However, this raises a few concerns I'd like to get community input on:
Code, not spec, runs in production. The spec is a design artifact, it describes intent. The implementation is what actually matters at runtime. Treating the spec as source of truth feels intuitive during development, but once the feature ships, the code is the truth. Isn't storing spec files in the remote repo counter-intuitive in the long run?
Repository bloat over time. In a repo with many contributors and long-lived projects, the number of spec files can grow substantially over the years. Even with archiving (openspec/changes/archive/), the cumulative volume raises questions about repo hygiene and discoverability.
Keeping spec and code in sync is hard. Code evolves through bug fixes, refactors, and follow-on features. Specs rarely get updated to reflect those changes. Over time, a committed spec can become misleading, describing a design that no longer reflects the implementation.
Beta Was this translation helpful? Give feedback.
All reactions