docs: recommend versioning models for constitution and specs

Constitution uses semantic versioning (major/minor/patch).
Specifications use branch-based workflows (feature branches,
reviewed and merged like code). Consistent with the existing
description in spec-driven.md line 21.
This commit is contained in:
Manfred Riem
2026-05-11 09:39:31 -05:00
parent 6fec3aa13d
commit 25175e2121

View File

@@ -356,7 +356,9 @@ Governance MUST ensure:
- Implementation gaps are addressed through specifications, not through untracked code changes
```
This article ensures that governance is not static and that specifications remain the authoritative source. When a gap or requirement emerges during implementation, teams may create a new specification, update an existing one, or regenerate derived artifacts—whichever approach fits their workflow—as long as the specification continues to drive implementation rather than the reverse. Constitution amendments follow semantic versioning—major for removed or redefined principles, minor for additions, patch for clarifications—creating an auditable trail of architectural decisions.
This article ensures that governance is not static and that specifications remain the authoritative source. When a gap or requirement emerges during implementation, teams may create a new specification, update an existing one, or regenerate derived artifacts—whichever approach fits their workflow—as long as the specification continues to drive implementation rather than the reverse.
The constitution follows semantic versioning—major for removed or redefined principles, minor for additions, patch for clarifications. Specifications are versioned through branch-based workflows—each feature specification lives in its own branch and is reviewed and merged like code. Together, these models create an auditable trail of architectural and product decisions.
#### Articles VII & VIII: Simplicity and Anti-Abstraction