fix: complete terminology cleanup - protocol specification → specification

NeilJo-GY · NeilJo-GY · commit aba4d2e3f9f7 · 2025-11-11T16:40:03.000+08:00
Additional cleanup of remaining 'protocol specification' references:
- SDS commands: implement, constitution, tasks, specify
- SDD commands: plan, specify
- Templates: spec-template, README, base templates
- 20+ occurrences updated across 10 files

Now fully consistent:
- Directory: specs/domain/ (domain specifications)
- Terminology: specification (not protocol specification)
- Only exception: actual protocol names (e.g. 'MCP protocol')
diff --git a/src/metaspec/templates/base/.metaspec/README.md.j2 b/src/metaspec/templates/base/.metaspec/README.md.j2
@@ -9,7 +9,7 @@
 This document is for **speckit developers** who want to:
 - Add new features to {{ name }}
 - Improve existing toolkit functionality
-- Define or evolve protocol specifications
+- Define or evolve domain specifications
 - Maintain toolkit quality
 
 If you just want to **use** {{ name }}, see the root `AGENTS.md` and `README.md`.
@@ -22,11 +22,11 @@ This speckit includes 16 AI-assisted development commands organized in three lay
 
 ### Layer 1: SDS (Spec-Driven Specification) - 5 Commands
 
-Define domain protocol specifications:
+Define domain domain specifications:
 
 - `/metaspec.sds.constitution` - Define protocol design principles
 - `/metaspec.sds.specify` - Define protocol entities, operations, validation rules
-- `/metaspec.sds.clarify` - Resolve ambiguities in protocol specification
+- `/metaspec.sds.clarify` - Resolve ambiguities in domain specification
 - `/metaspec.sds.checklist` - Generate quality checklist for protocol
 - `/metaspec.sds.analyze` - Check protocol consistency
 
diff --git a/src/metaspec/templates/base/specs/README.md.j2 b/src/metaspec/templates/base/specs/README.md.j2
@@ -182,7 +182,7 @@ Only for very simple toolkits without formal protocols. **Default: Always separa
 ## 💡 Best Practices
 
 1. **Protocol Spec First, Toolkit Spec Second**: Define Feature 1 (protocol spec) before Feature 2 (toolkit spec)
-2. **Separate Concerns**: Keep protocol specification separate from toolkit specification
+2. **Separate Concerns**: Keep domain specification separate from toolkit specification
 3. **Explicit Dependencies**: Feature 2 must explicitly depend on Feature 1
 4. **Clarify Early**: Use `/sdx.clarify` if requirements are unclear (before planning)
 5. **Validate Before Coding**: Use `/sdx.checklist` and `/sdx.analyze` before `/sdx.implement`
diff --git a/src/metaspec/templates/meta/README.md b/src/metaspec/templates/meta/README.md
@@ -203,7 +203,7 @@ generated-speckit/
 │       └── metaspec.archive.md
 │
 ├── specs/
-│   ├── protocol/    ← SDS output (protocol specifications)
+│   ├── domain/    ← SDS output (domain specifications)
 │   └── toolkit/     ← SDD output (toolkit specifications)
 │
 └── changes/         ← Evolution output (change management, at same level as specs/)
@@ -353,7 +353,7 @@ Project root
 ```
 
 **Key Principles**:
-1. **specs/domain/** - Independent protocol specifications, can be published and referenced separately
+1. **specs/domain/** - Independent domain specifications, can be published and referenced separately
 2. **specs/toolkit/** - Explicitly depends on protocol/, implements specific tools
 3. **changes/** - Manages evolution of both, maintains change history (at project root)
 
diff --git a/src/metaspec/templates/meta/sdd/commands/plan.md.j2 b/src/metaspec/templates/meta/sdd/commands/plan.md.j2
@@ -45,7 +45,7 @@ This command must handle two types of specifications:
 - ✅ Create `specs/toolkit/001-toolkit/plan.md` (the HOW)
 
 **Step 1c: For Feature 1 (Protocol Spec)** :
-- ⚠️ **Ask user**: "Feature 1 is a protocol specification and typically doesn't need a plan.md. Are you sure you want to create one?"
+- ⚠️ **Ask user**: "Feature 1 is a domain specification and typically doesn't need a plan.md. Are you sure you want to create one?"
 - If yes, proceed with simplified planning
 - If no, suggest: "Run `/metaspec.plan` in Feature 2 (toolkit spec) instead"
 
diff --git a/src/metaspec/templates/meta/sdd/commands/specify.md.j2 b/src/metaspec/templates/meta/sdd/commands/specify.md.j2
@@ -650,7 +650,7 @@ check-transition
 **What they are**: Spec-driven execution guides with embedded protocol knowledge
 **Where they go**: `templates/{source}/commands/` directory (organized by specification system source)  
 **How AI uses them**: Via `/` prefix in AI chat (Cursor, Windsurf, etc.)
-**Core purpose**: Guide AI to **produce outputs that comply with protocol specifications**
+**Core purpose**: Guide AI to **produce outputs that comply with domain specifications**
 
 **Key Distinction**:
 - ❌ **NOT**: "How to call CLI commands" (wrapper documentation)
@@ -698,7 +698,7 @@ model: claude-3-5-sonnet-20241022
 **IMPORTANT**: Slash Commands come from **TWO sources** and can be **composed**:
 
 #### Source 1: Protocol-Derived (Custom)
-- **From**: SDS protocol specification (`specs/domain/`)
+- **From**: SDS domain specification (`specs/domain/`)
 - **Nature**: Dynamic, protocol-specific, tailored
 - **Process**: Analyze protocol → Derive commands
 - **Examples**: `get-template`, `validate`, workflow actions
@@ -740,11 +740,11 @@ Option C: Composed (Recommended)
 
 #### Source 1: Protocol-Derived Commands (Custom)
 
-**Overview**: Derive commands by analyzing your protocol specification and extracting domain-specific terminology.
+**Overview**: Derive commands by analyzing your domain specification and extracting domain-specific terminology.
 
 **STEP 1: Analyze Protocol Specification**
 
-**Before defining Slash Commands**, analyze the SDS protocol specification in `specs/domain/`.
+**Before defining Slash Commands**, analyze the SDS domain specification in `specs/domain/`.
 
 **Questions to Ask**:
 
@@ -1190,7 +1190,7 @@ scripts/powershell/{script-name}.ps1 -Json "$ARGUMENTS"
 
 2. **AI Produces Content**
    - Read script output (file paths)
-   - Load protocol specification
+   - Load domain specification
    - Fill skeleton with protocol-compliant content
 
 3. **Verify Structure**
@@ -1215,7 +1215,7 @@ scripts/powershell/{script-name}.ps1 -Json "$ARGUMENTS"
 
 ```markdown
 ---
-description: Validate output against protocol specifications
+description: Validate output against domain specifications
 argument-hint: [file-to-validate]  # Optional: show expected arguments
 allowed-tools: Bash({toolkit-name}:validate:*)  # Only allow validation tools
 model: claude-3-5-haiku-20241022  # Can use lighter model for simple reminders
@@ -1380,7 +1380,7 @@ Each Slash Command contains:
 - [ ] Provides protocol-based templates
 - [ ] AI can produce compliant output without external reference
 
-**Summary**: Source 1 provides a 7-STEP process to derive custom Slash Commands from your protocol specification, ensuring domain-specific terminology and spec-driven execution.
+**Summary**: Source 1 provides a 7-STEP process to derive custom Slash Commands from your domain specification, ensuring domain-specific terminology and spec-driven execution.
 
 ---
 
diff --git a/src/metaspec/templates/meta/sds/commands/constitution.md.j2 b/src/metaspec/templates/meta/sds/commands/constitution.md.j2
@@ -1,5 +1,5 @@
 ---
-description: Define design principles and governance rules for the domain protocol specification
+description: Define design principles and governance rules for the domain specification
 ---
 
 ## User Input
@@ -14,7 +14,7 @@ You **MUST** consider the user input before proceeding (if not empty).
 
 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.
+Unlike toolkit development principles, this constitution focuses on **specification quality** - it guides decisions about entity definitions, validation rules, operation interfaces, and error handling specifications.
 
 Follow this execution flow:
 
@@ -141,7 +141,7 @@ Replace all placeholders with concrete text. The constitution should include:
 [Any domain-specific principles beyond the standard 6]
 
 ## Specification Constraints
-[Requirements for protocol specifications: formats, schemas, documentation]
+[Requirements for specifications: formats, schemas, documentation]
 
 ## Governance
 [Amendment process, review schedule, approval requirements]
diff --git a/src/metaspec/templates/meta/sds/commands/implement.md.j2 b/src/metaspec/templates/meta/sds/commands/implement.md.j2
@@ -14,7 +14,7 @@ You **MUST** consider the user input before proceeding (if not empty).
 
 **Goal**: Execute specification writing tasks systematically, following task order, respecting dependencies, and tracking progress.
 
-**Important**: This command runs AFTER `/metaspec.sds.tasks`. It is the execution engine for protocol specification development.
+**Important**: This command runs AFTER `/metaspec.sds.tasks`. It is the execution engine for specification development.
 
 ### Execution Flow
 
@@ -812,7 +812,7 @@ error_response:
    5. Create git tag v1.0.0
    
    💡 Suggested commit message:
-      docs: complete protocol specification system v1.0.0
+      docs: complete specification system v1.0.0
    ```
 
 #### 10. Incremental Saves
diff --git a/src/metaspec/templates/meta/sds/commands/specify.md.j2 b/src/metaspec/templates/meta/sds/commands/specify.md.j2
@@ -526,7 +526,7 @@ Brief overview of the protocol.
 
 ## Files
 
-- `spec.md` - Complete protocol specification
+- `spec.md` - Complete domain specification
 - `schema.{format}` - Schema files (if applicable)
 
 ## Status
@@ -535,7 +535,7 @@ Brief overview of the protocol.
 
 ## Quick Start
 
-{How to read and use this protocol specification}
+{How to read and use this domain specification}
 ```
 
 ### 6. Update Dependencies (If needed)
@@ -589,7 +589,7 @@ If this protocol depends on other protocols, document in spec.md:
 ✓ Validation Rules: {count} rules specified
 
 🔄 Next steps:
-1. Review protocol specification
+1. Review domain specification
 2. Run /metaspec.sds.analyze to check consistency
 3. Create toolkit with /metaspec.sdd.specify
 ```
diff --git a/src/metaspec/templates/meta/sds/commands/tasks.md.j2 b/src/metaspec/templates/meta/sds/commands/tasks.md.j2
@@ -12,7 +12,7 @@ You **MUST** consider the user input before proceeding (if not empty).
 
 ## Outline
 
-**Goal**: Break down protocol specification work into specific, executable tasks organized by sub-specification and ordered by dependencies.
+**Goal**: Break down specification work into specific, executable tasks organized by sub-specification and ordered by dependencies.
 
 **Important**: This command runs AFTER `/metaspec.sds.plan`. It transforms architecture plan into actionable specification tasks.
 
diff --git a/src/metaspec/templates/meta/templates/spec-template.md.j2 b/src/metaspec/templates/meta/templates/spec-template.md.j2
@@ -422,7 +422,7 @@ templates/
 ├── [library-spec-2]/       # Another library specification system
 │   ├── commands/
 │   └── templates/
-└── [custom]/               # Custom (derived from protocol specification)
+└── [custom]/               # Custom (derived from domain specification)
     ├── commands/           # Protocol-specific Slash Commands
     │   └── [command-name].md
     └── templates/          # Protocol entity templates
