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.
Support all three schools: new spec, update existing spec, or
regenerate derived artifacts. The only invariant is that specs
drive implementation, not the reverse, and gaps are addressed
through specifications rather than untracked code changes.
Constitution and specifications are the versioned sources of truth.
Plans and tasks are derived execution artifacts. Implementation gaps
are addressed through new specifications, preserving the feed-forward
dependency direction rather than retrofitting code back into specs.
Article VI now covers governance and versioning of all project
artifacts (constitution, specs, plans, tasks), not just constitution
amendments. This matches what spec-driven.md itself describes:
specifications versioned in branches, requirement changes propagating
across artifacts, and cross-artifact consistency.
Article IV (Requirement Quality and Coverage): driven by the
clarify/checklist/analyze pipeline that validates requirement
completeness, ambiguity, and traceability before planning.
Article V (Non-Functional Standards): ensures projects explicitly
specify performance, security, observability, and accessibility
requirements rather than defaulting to functional-only output.
Article VI (Governance and Versioning): codifies constitution
versioning and cross-artifact consistency propagation via the
/speckit.constitution command.
These three articles were missing from the original document despite
being actively enforced by existing templates and commands. Derived
by mapping every template and command back to constitutional
principles and identifying enforcement mechanisms with no article.
Two test assertions in test_timestamp_branches.py used the regex
`\d{3}` (exactly 3 digits) instead of `\d{3,}` (3 or more digits).
While the underlying shell scripts already handle spec numbers ≥ 1000
correctly — printf "%03d" and PowerShell '{0:000}' both expand naturally
beyond 3 digits, and all detection regexes use {3,} — the overly-strict
test assertions would fail with a misleading error if a fixture ever
contained 1000+ spec directories.
Documentation in README.md, spec-driven.md, and the CLI --branch-numbering
help text implied that sequential spec numbers are always 3 digits, which
could lead users to believe a hard limit of 999 exists.
Changes:
- tests/test_timestamp_branches.py: change two \d{3} assertions to \d{3,}
- src/specify_cli/__init__.py: clarify help text to show numbers expand past 999
- README.md: update --branch-numbering docs to note numbers expand beyond 3 digits
- spec-driven.md: update feature numbering description to include 4-digit example
Fixes#2093
Co-authored-by: alex-zwingli <alex-zwingli@users.noreply.github.com>
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Add automated markdown linting to ensure consistent formatting across
all markdown files in the repository.
Changes:
- Add .markdownlint-cli2.jsonc configuration
- Create .github/workflows/lint.yml for CI/CD integration
- Fix all 908 existing markdown errors across 27 files
- Enforce ATX-style headings and asterisk emphasis
- Set consistent 2-space list indentation
This prevents markdown errors after project initialization and
maintains high documentation quality standards.
