Spec-Kit Rules as part of Default Constitution

[DasBen]

While working a bit more with spec-kit i found out that adding spec-kit rules to the constitution can save a lot of headaches when manually editing files. An example while writing the spec and plan it can sometimes happen that AI write technical stuff into the spec and high level into the the plan. A simple constitution rule can catch this on using the analyze command:

**Documentation Separation of Concerns**:

Documentation follows strict separation between WHAT/WHY (spec.md) and HOW (plan.md):

- **spec.md - Product Perspective (What & Why)**:
  - MUST remain technology-agnostic
  - NO implementation details (frameworks, libraries, architecture patterns)
  - NO technical terminology except domain terms
  - Focus: User Stories, Requirements, Success Criteria
  - Question: "What should the system do and why?"
  - Target audience: Product Owner, Stakeholders, Domain Experts

- **plan.md - Engineering Perspective (How)**:
  - Contains ALL technical details and implementation decisions
  - Specifies frameworks, libraries, architecture patterns
  - Defines Technical Context (Language, Dependencies, Storage, Testing)
  - Documents Constitution Checks and Complexity Tracking
  - Question: "How do we implement the requirements from spec.md?"
  - Target audience: Developers, Tech Leads, Code Reviewers

- **Violations & Enforcement**:
  - Technical details in spec.md are a blocker for merge
  - spec.md reviews MUST verify technology-agnosticism
  - All "HOW" discussions belong in plan.md or code comments
  - Constitution Checks in plan.md validate separation

**Rationale**: Clear separation prevents mixing of business requirements and technical decisions. spec.md remains maintainable even when tech stack changes. Product discussions focus on user value instead of implementation.

I think adding something like this into the default constitution template could help the ai follow the spec-kit rules a lot more.