---
description: Define design principles and governance rules for the domain protocol specification
---

## User Input

```text
$ARGUMENTS
```

You **MUST** consider the user input before proceeding (if not empty).

## Outline

You are creating or updating the **protocol constitution** at `/memory/protocol-constitution.md`. This document defines the foundational principles that govern how this domain protocol is specified, ensuring it remains clear, implementable, and maintainable.

Unlike toolkit development principles, this constitution focuses on **protocol specification quality** - it guides decisions about entity definitions, validation rules, operation interfaces, and error handling specifications.

Follow this execution flow:

### 1. Load existing constitution (if any)

- Check for `/memory/protocol-constitution.md`
- If exists, load it and identify placeholder tokens `[ALL_CAPS_IDENTIFIER]`
- If new, use the protocol constitution template structure

### 2. Understand the protocol domain

**Critical**: Before defining principles, understand what protocol this specification defines:
- What domain does this protocol serve? (APIs, Data Formats, Communication Protocols?)
- What entities are needed? (Server, Tool, Resource, Message?)
- What operations are defined? (CRUD, Events, RPC?)
- What validation rules govern the protocol?

**Ask clarifying questions if unclear**:
- "What domain does this protocol target?"
- "What are the core protocol entities?"
- "What operations/interfaces does the protocol define?"

### 3. Derive protocol-specific principles

Based on the user input and protocol domain, populate these **standard protocol principles**:

#### **I. Entity Clarity**
- Entity definitions are complete and unambiguous
- All fields have explicit types and descriptions
- Required vs optional clearly specified
- Examples provided for every entity

**Rationale**: Clear entities enable consistent implementations across different tools.

#### **II. Validation Completeness**
- All constraints explicitly documented
- Error conditions clearly specified
- Edge cases addressed
- Validation rules traceable to domain requirements

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

#### **III. Operation Semantics**
- All operations have clear purposes
- Request/response schemas fully specified
- Side effects documented
- Idempotency requirements stated

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

#### **IV. Implementation Neutrality**
- Protocol doesn't mandate specific technologies
- Focuses on WHAT, not HOW
- Platform-agnostic specifications
- Multiple implementations possible

**Rationale**: Technology-neutral protocols have longer lifespans and wider adoption.

#### **V. Extensibility Design**
- Extension points clearly marked
- Backward compatibility rules defined
- Versioning strategy specified
- Deprecation process documented

**Rationale**: Protocols must evolve without breaking existing implementations.

#### **VI. Domain Fidelity**
- Respects domain standards and conventions
- References authoritative sources (RFCs, W3C, etc.)
- Domain terminology consistently used
- Domain constraints explicitly stated

**Rationale**: Domain-faithful protocols are easier to adopt and understand.

### 4. Collect/derive values for placeholders

- `[PROTOCOL_NAME]` - e.g., "MCP", "OpenAPI", "GraphQL"
- `[PROTOCOL_DOMAIN]` - e.g., "AI Model Communication", "API Specification", "Data Query"
- `[PRIMARY_ENTITIES]` - e.g., "Server, Tool, Resource", "Path, Operation, Schema"
- `[PRINCIPLE_N_NAME]` - Use standard protocol principles above
- `[PRINCIPLE_N_DESCRIPTION]` - Detailed description with protocol-specific examples
- `[GOVERNANCE_RULES]` - How to amend constitution, specification review process
- `[CONSTITUTION_VERSION]` - Semantic versioning (start at 1.0.0)
- `[RATIFICATION_DATE]` - Today's date (ISO 8601: YYYY-MM-DD)
- `[LAST_AMENDED_DATE]` - Today's date if new/updated

**Version bump rules**:
- **MAJOR**: Backward incompatible principle changes
- **MINOR**: New principles added or major expansions
- **PATCH**: Clarifications, wording fixes, examples added

### 5. Draft the constitution content

Replace all placeholders with concrete text. The constitution should include:

#### Structure:
```markdown
# [PROTOCOL_NAME] Constitution

## Protocol Purpose
[Brief description of what this protocol defines and what domain it serves]

## Core Principles

### I. Entity Clarity
[How entity definitions must be specified for this protocol]

### II. Validation Completeness
[What validation rules must be documented]

### III. Operation Semantics
[How protocol operations must be defined]

### IV. Implementation Neutrality
[How to ensure technology independence]

### V. Extensibility Design
[How protocol evolution is managed]

### VI. Domain Fidelity
[Domain standards this protocol adheres to]

## Additional Principles
[Any domain-specific principles beyond the standard 6]

## Specification Constraints
[Requirements for protocol specifications: formats, schemas, documentation]

## Governance
[Amendment process, review schedule, approval requirements]

**Version**: [CONSTITUTION_VERSION] | **Ratified**: [RATIFICATION_DATE] | **Last Amended**: [LAST_AMENDED_DATE]
```

### 6. Consistency propagation

Update these files to align with the constitution:

- `/specs/protocol/001-protocol-spec/spec.md` - Ensure entity definitions match Entity Clarity principle
- `/.metaspec/commands/sds.specify.md` - Reference constitution principles
- `/README.md` - Update protocol overview section

**For each file**:
- Read the file
- Identify sections that reference principles
- Update to match new/changed principles
- Mark with `<!-- Updated per protocol constitution v[VERSION] -->`

### 7. Generate Sync Impact Report

Prepend this as an HTML comment at the top of constitution file:

```html
<!--
Protocol Constitution Update Report
====================================
Version Change: [OLD_VERSION] → [NEW_VERSION]
Rationale: [MAJOR|MINOR|PATCH bump reason]

Modified Principles:
- [OLD_PRINCIPLE_NAME] → [NEW_PRINCIPLE_NAME]
- [PRINCIPLE_NAME]: [description of changes]

Added Principles:
- [NEW_PRINCIPLE_NAME]: [brief description]

Removed Principles:
- [OLD_PRINCIPLE_NAME]: [deprecation reason]

Affected Files:
✅ /specs/protocol/spec.md - Updated entity requirements
⚠️  /README.md - Pending manual update for protocol overview

Follow-up TODOs:
- [ ] Update protocol examples
- [ ] Review existing specifications against new principles

Generated: [ISO_DATE]
-->
```

### 8. Validation checklist

Before finalizing:

- [ ] No remaining `[PLACEHOLDER]` tokens
- [ ] Version follows semantic versioning
- [ ] Dates in ISO 8601 format (YYYY-MM-DD)
- [ ] All 6 standard protocol principles present
- [ ] Each principle has clear description and rationale
- [ ] Principles are verifiable (can check spec compliance)
- [ ] Governance section includes amendment process
- [ ] Domain Fidelity principle references actual standards
- [ ] Implementation Neutrality principle avoids technology mandates

### 9. Write constitution file

- Write to `/memory/protocol-constitution.md`
- Ensure proper Markdown formatting
- No trailing whitespace
- Single blank line between sections
- Wrap long lines at ~100 characters

### 10. Output summary to user

Provide:

```
✅ Protocol constitution updated to v[VERSION]

📋 Changes:
- [Summary of what changed]
- [New principles added]
- [Modified principles]

📁 Updated files:
- /memory/protocol-constitution.md
- /specs/protocol/spec.md (if exists)

⚠️  Files needing manual review:
- [List any files that couldn't be auto-updated]

🔄 Next steps:
1. Review the constitution in /memory/protocol-constitution.md
2. Use /metaspec.sds.specify to define protocol entities aligned with these principles
3. Reference these principles during protocol design

💡 Suggested commit message:
   docs: adopt protocol constitution v[VERSION] ([principle summary])
```

## Important Notes

1. **Constitution is for the protocol, not implementations**
   - This defines how to SPECIFY the protocol
   - It does NOT define how to IMPLEMENT the protocol
   - Focus on entity definitions, validation rules, operation interfaces

2. **Standard vs Domain-Specific Principles**
   - Always include the 6 standard protocol principles
   - Add domain-specific principles as needed (e.g., "RESTful Conventions" for APIs)
   - Don't remove standard principles without strong justification

3. **Examples Matter**
   - Each principle should include protocol-specific examples
   - Examples should use the actual entities from this protocol
   - Bad: "Entities should be clear"
   - Good: "Entity `Tool` must specify `name` (string, required), `description` (string, required), `inputSchema` (JSON Schema, required)"

4. **Specification-First Language**
   - Write for protocol designers reading this document
   - Use imperative language (MUST, SHOULD, MAY)
   - Avoid ambiguity ("usually", "typically" → specify exact rules)
   - Include anti-patterns (what NOT to specify)

5. **Version Control**
   - Never decrement version
   - Document reason for every version bump
   - Keep sync report for traceability

