docs: unify terminology in template files

- templates/README.md: Update SDS command descriptions
  - 'protocol specification' → 'domain specification'
  - 'protocol principles' → 'specification design principles'
- SDS command templates:
  - analyze.md.j2: Update all protocol references
  - checklist.md.j2: Batch replace protocol → specification
  - constitution.md.j2: Update standard principles descriptions

Author: NeilJo-GY

src/metaspec/templates/README.md

@@ -121,22 +121,22 @@ Development methodologies organized by lifecycle:
 
 ### `meta/` - MetaSpec Three-Layer Architecture
 
-**Purpose**: AI-assisted workflow for developing the speckit itself using a three-layer command architecture that separates protocol specification from toolkit development.
+**Purpose**: AI-assisted workflow for developing the speckit itself using a three-layer command architecture that separates domain specification from toolkit development.
 
 #### Three Layers
 
 ##### `meta/sds/commands/` - Spec-Driven Specification (8 commands)
 
-**Purpose**: Define domain protocol specifications
+**Purpose**: Define domain specifications
 
-- `constitution.md.j2` - Define protocol design principles
-- `specify.md.j2` - Define protocol entities, operations, validation rules
-- `clarify.md.j2` - Resolve protocol ambiguities
-- `plan.md.j2` - Plan protocol architecture and sub-specifications
-- `tasks.md.j2` - Break down protocol specification work
-- `implement.md.j2` - Write protocol specification documents
-- `checklist.md.j2` - Generate quality checklist for protocol specification
-- `analyze.md.j2` - Check protocol consistency
+- `constitution.md.j2` - Define specification design principles
+- `specify.md.j2` - Define specification entities, operations, validation rules
+- `clarify.md.j2` - Resolve specification ambiguities
+- `plan.md.j2` - Plan specification architecture and sub-specifications
+- `tasks.md.j2` - Break down specification work
+- `implement.md.j2` - Write specification documents
+- `checklist.md.j2` - Generate quality checklist for specification
+- `analyze.md.j2` - Check specification consistency
 
 **Generated to**: `.metaspec/commands/metaspec.sds.*`
 **Works with**: `specs/protocol/` directory
@@ -219,10 +219,10 @@ my-speckit/
 ```bash
 cd my-speckit
 
-# Phase 1: Define protocol (SDS)
-/metaspec.sds.constitution  # Define protocol principles
-/metaspec.sds.specify       # Create protocol specifications
-/metaspec.sds.analyze       # Check protocol consistency
+# Phase 1: Define specification (SDS)
+/metaspec.sds.constitution  # Define specification design principles
+/metaspec.sds.specify       # Create domain specifications
+/metaspec.sds.analyze       # Check specification consistency
 
 # Phase 2: Develop toolkit (SDD)
 /metaspec.sdd.constitution  # Define toolkit principles

src/metaspec/templates/meta/sds/commands/analyze.md.j2

@@ -1,5 +1,5 @@
 ---
-description: Perform protocol specification quality analysis - read-only analysis for protocol consistency
+description: Perform specification quality analysis - read-only analysis for specification consistency
 ---
 
 ## User Input
@@ -12,9 +12,9 @@ You **MUST** consider the user input before proceeding (if not empty).
 
 ## Goal
 
-Identify inconsistencies, ambiguities, and gaps in protocol specifications. **READ-ONLY** analysis - no file modifications.
+Identify inconsistencies, ambiguities, and gaps in domain specifications. **READ-ONLY** analysis - no file modifications.
 
-**Focus**: Protocol specification quality (WHAT the protocol is), NOT toolkit implementation (HOW to implement).
+**Focus**: Domain specification quality (WHAT the specification is), NOT toolkit implementation (HOW to implement).
 
 ## Operating Constraints
 
@@ -447,16 +447,16 @@ Would you like me to suggest concrete fixes for the top 5 issues?
 
 ## Important Notes
 
-1. **Protocol-Focused Analysis**
-   - Only analyze protocol specifications
+1. **Specification-Focused Analysis**
+   - Only analyze domain specifications
    - Do NOT check toolkit implementation details
    - Do NOT reference plan.md, tasks.md, or src/ code
-   - Focus: WHAT the protocol is, not HOW to implement it
+   - Focus: WHAT the specification is, not HOW to implement it
 
 2. **Constitution Authority**
    - Constitution violations are always CRITICAL
-   - Protocol must adjust, not constitution
-   - Protocol-specific principles apply
+   - Specification must adjust, not constitution
+   - Specification-specific principles apply
 
 3. **Read-Only Analysis**
    - No file modifications

src/metaspec/templates/meta/sds/commands/checklist.md.j2

@@ -1,17 +1,17 @@
 ---
-description: Generate quality checklist for protocol specification - validates protocol quality, NOT implementation correctness
+description: Generate quality checklist for specification - validates protocol quality, NOT implementation correctness
 ---
 
 ## Checklist Purpose: "Unit Tests for Protocol Specifications"
 
-**CRITICAL CONCEPT**: Checklists are **UNIT TESTS FOR SPECIFICATION WRITING** - they validate the quality, clarity, and completeness of protocol specifications.
+**CRITICAL CONCEPT**: Checklists are **UNIT TESTS FOR SPECIFICATION WRITING** - they validate the quality, clarity, and completeness of specifications.
 
 **NOT for implementation verification**:
 - ❌ "Verify parser handles protocol correctly"
 - ❌ "Test validator catches protocol violations"
 - ❌ "Confirm toolkit implements protocol"
 
-**FOR protocol specification quality validation**:
+**FOR specification quality validation**:
 - ✅ "Are all protocol entities clearly defined? [Completeness]"
 - ✅ "Are operation schemas consistently specified? [Consistency]"
 - ✅ "Are error codes documented with examples? [Completeness]"
@@ -213,7 +213,7 @@ Test if protocol follows constitution principles:
 - Are domain standards followed? [Consistency, Constitution]
 
 #### **Ambiguities & Gaps**
-Test for protocol specification issues:
+Test for specification issues:
 - Are vague terms quantified ("valid", "appropriate")? [Ambiguity]
 - Are conflicting requirements identified? [Conflict]
 - Are missing definitions noted? [Gap]
@@ -344,7 +344,7 @@ Test for protocol specification issues:
 - [ ] CHK003 - Confirm toolkit CLI works with protocol
 ```
 
-**✅ CORRECT - Testing protocol specification quality**:
+**✅ CORRECT - Testing specification quality**:
 ```markdown
 - [ ] CHK001 - Are protocol parsing requirements specified? [Completeness, Spec §Parser Requirements]
 - [ ] CHK002 - Are protocol validation rules documented? [Completeness, Spec §Validation Rules]
@@ -376,7 +376,7 @@ Test for protocol specification issues:
 
 🎯 Purpose:
 This checklist validates the quality of protocol entity definitions in spec.md.
-It does NOT test if toolkit implements protocol, but whether the protocol specification is:
+It does NOT test if toolkit implements protocol, but whether the specification is:
 - Complete (all entities defined)
 - Clear (types, constraints explicit)
 - Consistent (follows constitution)

src/metaspec/templates/meta/sds/commands/constitution.md.j2

@@ -39,7 +39,7 @@ Follow this execution flow:
 
 ### 3. Derive protocol-specific principles
 
-Based on the user input and protocol domain, populate these **standard protocol principles**:
+Based on the user input and specification domain, populate these **standard specification design principles**:
 
 #### **I. Entity Clarity**
 - Entity definitions are complete and unambiguous
@@ -94,8 +94,8 @@ Based on the user input and protocol domain, populate these **standard protocol
 - `[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
+- `[PRINCIPLE_N_NAME]` - Use standard specification design principles above
+- `[PRINCIPLE_N_DESCRIPTION]` - Detailed description with specification-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)
@@ -203,7 +203,7 @@ Before finalizing:
 - [ ] No remaining `[PLACEHOLDER]` tokens
 - [ ] Version follows semantic versioning
 - [ ] Dates in ISO 8601 format (YYYY-MM-DD)
-- [ ] All 6 standard protocol principles present
+- [ ] All 6 standard specification design principles present
 - [ ] Each principle has clear description and rationale
 - [ ] Principles are verifiable (can check spec compliance)
 - [ ] Governance section includes amendment process
@@ -240,7 +240,7 @@ Provide:
 🔄 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
+3. Reference these principles during specification design
 
 💡 Suggested commit message:
    docs: adopt protocol constitution v[VERSION] ([principle summary])
@@ -254,7 +254,7 @@ Provide:
    - Focus on entity definitions, validation rules, operation interfaces
 
 2. **Standard vs Domain-Specific Principles**
-   - Always include the 6 standard protocol principles
+   - Always include the 6 standard specification design principles
    - Add domain-specific principles as needed (e.g., "RESTful Conventions" for APIs)
    - Don't remove standard principles without strong justification
 
@@ -265,7 +265,7 @@ Provide:
    - 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
+   - Write for specification designers reading this document
    - Use imperative language (MUST, SHOULD, MAY)
    - Avoid ambiguity ("usually", "typically" → specify exact rules)
    - Include anti-patterns (what NOT to specify)