# {{ name }} Constitution

> Version 1.0.0 | Ratified: {{ date }} | Last Updated: {{ date }}

---

## Part I: Project Core Values

**Purpose**: Foundational values that govern this spec-driven toolkit

### 1. AI-First Design

Every feature must be optimized for AI agent collaboration.

**Rules**:
- Clear error messages with examples
- Consistent naming conventions
- Explicit behavior (no magic defaults)
- All behavior documented

**Rationale**: AI agents need clear feedback to correct mistakes and learn patterns.

### 2. Progressive Enhancement

Ship minimal viable product first, iterate based on feedback.

**Rules**:
- Define MVP scope clearly
- Add features incrementally
- Maintain backward compatibility
- Document feature maturity (alpha, beta, stable)

**Rationale**: Start simple, grow based on real user needs.

### 3. Minimal Viable Abstraction

Avoid over-engineering. Keep it as simple as possible.

**Rules**:
- Start with concrete examples
- Abstract only after seeing 3+ similar patterns
- Each abstraction must add clear value
- Remove abstractions that don't earn their keep

**Rationale**: Complexity is the enemy of maintainability.

### 4. Domain Specificity

Focus on {{ domain }} domain. Generic toolkits are weak toolkits.

**Rules**:
- Research domain standards before designing
- Follow domain conventions and best practices
- Include domain-specific validation
- Don't force-fit generic solutions

**Rationale**: Domain focus creates real value for users.

<!-- Managed by /speckit.constitution -->

---

## Part II: Specification Design Principles

**Purpose**: Guidelines for defining {{ domain }} specifications (entities, validation rules, operations)

### 1. Entity Clarity

All entity definitions must be complete and unambiguous.

**Rules**:
- All fields have explicit types and descriptions
- Required vs optional clearly specified
- Examples provided for every entity
- Field naming follows consistent conventions

**Rationale**: Clear entities enable consistent implementations.

### 2. Validation Completeness

All constraints must be explicitly documented.

**Rules**:
- Document all validation rules
- Specify error conditions clearly
- Address edge cases
- Validation rules traceable to domain requirements

**Rationale**: Complete validation specs prevent implementation divergence.

### 3. Operation Semantics

All operations must have clear purposes and interfaces.

**Rules**:
- Request/response schemas fully specified
- Side effects documented
- Idempotency requirements stated
- Error handling explicit

**Rationale**: Well-defined operations enable interoperable implementations.

### 4. Implementation Neutrality

Specifications must not mandate specific technologies.

**Rules**:
- Focus on WHAT, not HOW
- Platform-agnostic specifications
- Multiple implementations possible
- Avoid technology-specific assumptions

**Rationale**: Technology-neutral specifications have longer lifespans.

### 5. Extensibility Design

Extension points must be clearly marked.

**Rules**:
- Extension points documented
- Backward compatibility rules defined
- Versioning strategy specified
- Deprecation process documented

**Rationale**: Specifications must evolve without breaking implementations.

### 6. Domain Fidelity

Respect domain standards and conventions.

**Rules**:
{% if domain == "mcp" %}
- Follow MCP specification (version compatibility)
- Tool/Resource/Prompt structure compliance
- JSON-RPC 2.0 message format
- Standard error codes
{% elif domain == "marketing" %}
- Follow marketing industry standards
- Use standard terminology (CPM, CTR, ROAS, CPA)
- Campaign lifecycle conventions
- Attribution model specifications
{% elif domain == "web" %}
- Follow web standards (W3C, WHATWG)
- RESTful API conventions
- HTTP semantics (methods, status codes)
- Content-Type and encoding standards
{% else %}
- Reference authoritative sources (RFCs, standards bodies)
- Use domain terminology consistently
- Follow industry conventions
- Document domain constraints explicitly
{% endif %}

**Rationale**: Domain-faithful specifications are easier to adopt.

<!-- Managed by /metaspec.sds.constitution -->

---

## Part III: Toolkit Implementation Principles

**Purpose**: Guidelines for building the toolkit (parser, validator, CLI, generator)

### 1. Entity-First Design

Start with minimal viable entity definition.

**Rules**:
- Define 3-5 core fields for MVP
- Use type validation (Pydantic, Zod, etc.)
- Required fields only for essential data
- Support progressive enhancement

**Rationale**: Simple entities are easier to understand and validate.

### 2. Validator Extensibility

Core validator handles structure, support custom rules.

**Rules**:
- Plugin system for custom validators
- Clear error messages with field path
- Include fix suggestions in errors
- Validation performance: <100ms for typical specs

**Rationale**: Different use cases need different validation logic.

### 3. Spec-First Development

Users write specifications first, toolkit processes them.

**Rules**:
- Specifications are declarative (what, not how)
- Human-readable formats (YAML/JSON/Markdown)
- Specifications are version-controlled
- Generate code from specs, not reverse

**Rationale**: Spec-first enables AI agents to generate and validate.

### 4. AI-Agent Friendly

Optimize for AI agent usage.

**Rules**:
- Error messages show fix examples
- Consistent naming conventions (snake_case fields, kebab-case CLI)
- Documentation includes common patterns
- Templates for common use cases

**Rationale**: AI agents need clear patterns to learn from.

### 5. Progressive Enhancement

Ship MVP first, add features incrementally.

**Rules**:
- MVP: init + validate commands
- Phase 2: generate command
- Phase 3: execute/test commands
- Phase 4: report/analytics
- Semantic versioning strictly followed

**Rationale**: Validate value before building advanced features.

### 6. Automated Quality

Testing and validation are automated.

**Rules**:
- Unit tests for all validators
- Integration tests for workflows
- Example specs as test cases
- CI/CD for quality checks

**Rationale**: Automation prevents regression and improves confidence.

<!-- Managed by /metaspec.sdd.constitution -->

---

## Governance

### Amendment Process

**Part I (Project Core Values)**:
- Changes require project-wide review
- Breaking changes need major version bump
- Rationale must be documented

**Part II (Specification Design)**:
- Updated via `/metaspec.sds.constitution`
- Changes require minor version bump
- Consistency check with existing specs

**Part III (Toolkit Implementation)**:
- Updated via `/metaspec.sdd.constitution`
- Changes require minor version bump
- Consistency check with existing code

### Version Bump Rules

- **MAJOR**: Part I changes (core values modified)
- **MINOR**: Part II or Part III changes (new principles added)
- **PATCH**: Clarifications, examples, wording fixes

### Compliance

All specifications and code must follow this constitution. Use validation commands to check compliance:
- `/metaspec.sds.checklist` - Validate specification quality
- `/metaspec.sdd.checklist` - Validate toolkit implementation

---

**Constitution Version**: 1.0.0  
**Generated by**: MetaSpec {{ metaspec_version }}  
**Domain**: {{ domain }}
