From 25175e212164203882db8088e0c108e08be26006 Mon Sep 17 00:00:00 2001
From: Manfred Riem <15701806+mnriem@users.noreply.github.com>
Date: Mon, 11 May 2026 09:39:31 -0500
Subject: [PATCH] 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.
---
 spec-driven.md | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/spec-driven.md b/spec-driven.md
index 216906517..c97439a1a 100644
--- a/spec-driven.md
+++ b/spec-driven.md
@@ -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