@cluesmith/codev 2.0.0-rc.56 → 2.0.0-rc.58

package/skeleton/porch/prompts/understand.md

@@ -30,7 +30,7 @@ TICK is appropriate when:
 - [ ] Requirements are clear
 - [ ] No architectural changes needed
 
-If NOT appropriate, signal: `<signal>NEEDS_SPIDER</signal>`
+If NOT appropriate, signal: `<signal>NEEDS_SPIR</signal>`
 
 ### 3. Document Understanding
 
@@ -58,4 +58,4 @@ When understanding is complete:
 
 - DO NOT start implementing
 - DO NOT create new spec files (amend existing)
-- Keep scope small - if > 300 LOC, recommend SPIDER instead
+- Keep scope small - if > 300 LOC, recommend SPIR instead

package/skeleton/protocol-schema.json

@@ -2,7 +2,7 @@
   "$schema": "https://json-schema.org/draft/2020-12/schema",
   "$id": "https://codev.dev/protocol-schema.json",
   "title": "Codev Protocol Definition",
-  "description": "Schema for porch protocol definitions (SPIDER, TICK, BUGFIX, etc.)",
+  "description": "Schema for porch protocol definitions (SPIR, TICK, BUGFIX, etc.)",
   "type": "object",
   "required": ["name", "phases"],
   "properties": {
@@ -12,12 +12,12 @@
     },
     "name": {
       "type": "string",
-      "description": "Protocol name (e.g., 'spider', 'tick', 'bugfix')",
+      "description": "Protocol name (e.g., 'spir', 'tick', 'bugfix')",
       "pattern": "^[a-z][a-z0-9-]*$"
     },
     "alias": {
       "type": "string",
-      "description": "Alternative name for the protocol (e.g., 'spir' for spider)"
+      "description": "Alternative name for the protocol (e.g., 'spider' for spir)"
     },
     "version": {
       "type": "string",

package/skeleton/protocols/bugfix/builder-prompt.md

@@ -39,7 +39,7 @@ Follow the BUGFIX protocol: `codev/protocols/bugfix/protocol.md`
 
 If the fix is too complex (> 300 LOC or architectural changes), notify the Architect via:
 ```bash
-af send architect "Issue #{{issue.number}} is more complex than expected. [Reason]. Recommend escalating to SPIDER/TICK."
+af send architect "Issue #{{issue.number}} is more complex than expected. [Reason]. Recommend escalating to SPIR/TICK."
 ```
 {{/if}}
 

package/skeleton/protocols/bugfix/prompts/pr.md

@@ -42,24 +42,9 @@ EOF
 )"
 ```
 
-### 2. Run CMAP Review
+### 2. Signal Completion
 
-Run 3-way parallel consultation on the PR:
-
-```bash
-consult --model gemini pr <PR_NUMBER> &
-consult --model codex pr <PR_NUMBER> &
-consult --model claude pr <PR_NUMBER> &
-```
-
-All three should run in the background (`run_in_background: true`).
-
-### 3. Address Feedback
-
-Review the consultation results:
-- Fix any issues identified by reviewers
-- Push updates to the PR branch
-- Re-run CMAP if substantial changes were made
+After the PR is created, signal completion. Porch will run consultation automatically via the verify step. If reviewers request changes, you'll be respawned with their feedback.
 
 ## Signals
 

package/skeleton/protocols/experiment/protocol.md

@@ -10,7 +10,7 @@ Disciplined experimentation: Each experiment gets its own directory with `notes.
 
 **Use for**: Testing approaches, evaluating models, prototyping, proof-of-concept work, research spikes
 
-**Skip for**: Production code (use SPIDER), simple one-off scripts, well-understood implementations (use TICK)
+**Skip for**: Production code (use SPIR), simple one-off scripts, well-understood implementations (use TICK)
 
 ## Structure
 
@@ -141,7 +141,7 @@ What should be done based on findings?
 
 ## Integration with Other Protocols
 
-### Experiment → SPIDER
+### Experiment → SPIR
 When an experiment validates an approach for production use:
 
 1. Create a specification referencing the experiment
@@ -225,5 +225,5 @@ Determine if Redis caching improves API response times for repeated queries.
 - Memory usage: 50MB for 10k cached responses
 
 ## Next Steps
-Create SPIDER spec for production caching implementation.
+Create SPIR spec for production caching implementation.
 ```

package/skeleton/protocols/experiment/templates/notes.md

@@ -88,7 +88,7 @@ Based on these findings:
 
 1. **Immediate**: What should happen right after this experiment?
 2. **Follow-up experiments**: What new questions emerged?
-3. **Production path**: If validated, what's needed for production? (SPIDER spec?)
+3. **Production path**: If validated, what's needed for production? (SPIR spec?)
 
 ## References
 

package/skeleton/protocols/maintain/protocol.md

@@ -479,7 +479,7 @@ MAINTAIN is an **operational protocol**, not a feature development protocol:
 | Review | No |
 | 3-Way Consultation | **Yes** (before creating PR) |
 
-**Exception**: If MAINTAIN reveals need for architectural changes, those should follow SPIDER.
+**Exception**: If MAINTAIN reveals need for architectural changes, those should follow SPIR.
 
 ---
 

package/skeleton/protocols/protocol-schema.json

@@ -8,7 +8,7 @@
   "properties": {
     "name": {
       "type": "string",
-      "description": "Protocol identifier (e.g., 'spider', 'tick', 'bugfix')"
+      "description": "Protocol identifier (e.g., 'spir', 'tick', 'bugfix')"
     },
     "version": {
       "type": "string",

package/skeleton/protocols/{spider → spir}/builder-prompt.md

@@ -21,7 +21,7 @@ You are running in STRICT mode. This means:
 {{/if}}
 
 ## Protocol
-Follow the SPIDER protocol: `codev/protocols/spider/protocol.md`
+Follow the SPIR protocol: `codev/protocols/spir/protocol.md`
 Read and internalize the protocol before starting any work.
 
 {{#if spec}}

package/skeleton/protocols/{spider → spir}/prompts/implement.md

@@ -1,6 +1,6 @@
 # IMPLEMENT Phase Prompt
 
-You are executing the **IMPLEMENT** phase of the SPIDER protocol.
+You are executing the **IMPLEMENT** phase of the SPIR protocol.
 
 ## Your Goal
 

package/skeleton/protocols/{spider → spir}/prompts/plan.md

@@ -1,6 +1,6 @@
 # PLAN Phase Prompt
 
-You are executing the **PLAN** phase of the SPIDER protocol.
+You are executing the **PLAN** phase of the SPIR protocol.
 
 ## Your Goal
 
@@ -14,10 +14,6 @@ Transform the approved specification into an executable implementation plan with
 - **Spec File**: `codev/specs/{{project_id}}-{{title}}.md`
 - **Plan File**: `codev/plans/{{project_id}}-{{title}}.md`
 
-## CRITICAL: Multi-Agent Consultation is MANDATORY
-
-The SPIDER protocol **requires** consultation with GPT-5 Codex AND Gemini Pro at specific checkpoints. This is BLOCKING - you cannot proceed without completing consultations.
-
 ## Prerequisites
 
 Before planning, verify:
@@ -72,51 +68,15 @@ Phase 3: API Endpoints (depends on Phase 2)
 Phase 4: Frontend Integration (depends on Phase 3)
 ```
 
-### 5. MANDATORY: First Consultation (After Draft)
-
-After completing the initial plan draft:
-
-```bash
-# Run consultations in parallel (REQUIRED)
-consult --model gemini plan {{project_id}} &
-consult --model codex plan {{project_id}} &
-wait
-```
-
-- Review ALL feedback from both models
-- Update the plan with incorporated feedback
-- Add a **Consultation Log** section documenting:
-  - Key feedback received
-  - Changes made in response
-  - Any feedback intentionally not incorporated (with reasoning)
-
-### 6. Human Review
-
-After consultation feedback is incorporated:
-- Present the plan for human review
-- Wait for approval or change requests
-- If changes requested, make them and proceed to Step 7
-
-### 7. MANDATORY: Second Consultation (After Human Feedback)
-
-After incorporating human feedback:
+### 5. Finalize
 
-```bash
-# Run consultations again (REQUIRED)
-consult --model gemini plan {{project_id}} &
-consult --model codex plan {{project_id}} &
-wait
-```
-
-- Update Consultation Log with new feedback
-- Incorporate changes
-- Prepare final plan for approval
+After completing the plan draft, signal completion. Porch will run 3-way consultation (Gemini, Codex, Claude) automatically via the verify step. If reviewers request changes, you'll be respawned with their feedback.
 
 ## Output
 
 Create the plan file at `codev/plans/{{project_id}}-{{title}}.md`.
 
-Use the plan template from `codev/protocols/spider/templates/plan.md` if available.
+Use the plan template from `codev/protocols/spir/templates/plan.md` if available.
 
 ### Plan Structure
 
@@ -148,18 +108,6 @@ Brief summary of what will be implemented.
 - [Risk 1]: [Mitigation]
 - [Risk 2]: [Mitigation]
 
-## Consultation Log
-
-### First Consultation (After Draft)
-- **Gemini Feedback**: [Summary]
-- **Codex Feedback**: [Summary]
-- **Changes Made**: [List]
-- **Not Incorporated**: [List with reasons]
-
-### Second Consultation (After Human Feedback)
-- **Gemini Feedback**: [Summary]
-- **Codex Feedback**: [Summary]
-- **Changes Made**: [List]
 ```
 
 ## Signals
@@ -171,16 +119,6 @@ Emit appropriate signals based on your progress:
   <signal>PLAN_DRAFTED</signal>
   ```
 
-- After incorporating consultation feedback:
-  ```
-  <signal>CONSULTATION_INCORPORATED</signal>
-  ```
-
-- After final plan is ready for human approval:
-  ```
-  <signal>PLAN_READY_FOR_APPROVAL</signal>
-  ```
-
 ## Commit Cadence
 
 Make commits at these milestones:
@@ -196,16 +134,14 @@ git add codev/plans/{{project_id}}-{{title}}.md
 
 ## Important Notes
 
-1. **Consultation is MANDATORY** - Cannot skip GPT-5 + Gemini reviews
-2. **No time estimates** - Don't include hours/days/weeks
+1. **No time estimates** - Don't include hours/days/weeks
 3. **Be specific about files** - Exact paths, not "the config file"
 4. **Keep phases small** - 1-3 files per phase is ideal
 5. **Document dependencies clearly** - Prevents blocked work
-6. **Document consultations** - Maintain the Consultation Log section
 
 ## What NOT to Do
 
-- Don't skip consultations (they are BLOCKING)
+- Don't run `consult` commands yourself (porch handles consultations)
 - Don't write code (that's for Implement phase)
 - Don't estimate time (meaningless in AI development)
 - Don't create phases that can't be independently tested

package/skeleton/protocols/{spider → spir}/prompts/review.md

@@ -1,14 +1,10 @@
 # REVIEW Phase Prompt
 
-You are executing the **REVIEW** phase of the SPIDER protocol.
+You are executing the **REVIEW** phase of the SPIR protocol.
 
 ## Your Goal
 
-Perform a comprehensive review, document lessons learned, run final consultation, and prepare for PR submission.
-
-## CRITICAL: Final Consultation Before PR
-
-The SPIDER protocol **requires** a final consultation with GPT-5 Codex AND Gemini Pro before submitting the PR. This ensures the complete implementation is reviewed.
+Perform a comprehensive review, document lessons learned, and prepare for PR submission.
 
 ## Context
 
@@ -92,7 +88,7 @@ Brief description of what was implemented.
 - [Insight 2]
 
 ### Methodology Improvements
-- [Suggested improvement to SPIDER protocol]
+- [Suggested improvement to SPIR protocol]
 - [Suggested improvement to tooling]
 
 ## Technical Debt
@@ -118,22 +114,9 @@ Before PR:
 - [ ] No uncommitted changes: `git status`
 - [ ] Review document complete
 
-### 6. MANDATORY: Final Consultation (PR-Ready Review)
-
-**Before creating the PR, run final consultation:**
-
-```bash
-# Run consultations in parallel (REQUIRED)
-consult --model gemini --type pr-ready spec {{project_id}} &
-consult --model codex --type pr-ready spec {{project_id}} &
-wait
-```
-
-- Review ALL feedback from both models
-- Address any final issues identified
-- This is the last chance to catch problems before PR
+### 6. Create Pull Request
 
-### 7. Create Pull Request
+After the review document is complete, signal completion. Porch will run 3-way consultation (Gemini, Codex, Claude) automatically via the verify step. If reviewers request changes, you'll be respawned with their feedback.
 
 Prepare PR with:
 
@@ -187,8 +170,7 @@ Emit appropriate signals based on your progress:
 
 ## Important Notes
 
-1. **Final consultation is MANDATORY** - Cannot skip GPT-5 + Gemini reviews before PR
-2. **Be honest in lessons learned** - Future you will thank present you
+1. **Be honest in lessons learned** - Future you will thank present you
 3. **Document deviations** - They're not failures, they're learnings
 4. **Update methodology** - If you found a better way, document it
 5. **Don't skip the checklist** - It catches last-minute issues
@@ -196,7 +178,7 @@ Emit appropriate signals based on your progress:
 
 ## What NOT to Do
 
-- Don't skip final consultation (it's BLOCKING)
+- Don't run `consult` commands yourself (porch handles consultations)
 - Don't skip lessons learned ("nothing to report")
 - Don't merge your own PR (Architect handles integration)
 - Don't leave uncommitted changes

package/skeleton/protocols/{spider → spir}/prompts/specify.md

@@ -1,6 +1,6 @@
 # SPECIFY Phase Prompt
 
-You are executing the **SPECIFY** phase of the SPIDER protocol.
+You are executing the **SPECIFY** phase of the SPIR protocol.
 
 ## Your Goal
 
@@ -13,10 +13,6 @@ Create a comprehensive specification document that thoroughly explores the probl
 - **Current State**: {{current_state}}
 - **Spec File**: `codev/specs/{{project_id}}-{{title}}.md`
 
-## CRITICAL: Multi-Agent Consultation is MANDATORY
-
-The SPIDER protocol **requires** consultation with GPT-5 Codex AND Gemini Pro at specific checkpoints. This is BLOCKING - you cannot proceed without completing consultations.
-
 ## Process
 
 ### 0. Check for Existing Spec (ALWAYS DO THIS FIRST)
@@ -80,45 +76,9 @@ Define measurable acceptance criteria:
 - Non-functional requirements (performance, security)
 - Test scenarios
 
-### 6. MANDATORY: First Consultation (After Draft)
-
-After completing the initial spec draft:
-
-```bash
-# Run consultations in parallel (REQUIRED)
-consult --model gemini spec {{project_id}} &
-consult --model codex spec {{project_id}} &
-wait
-```
-
-- Review ALL feedback from both models
-- Update the spec with incorporated feedback
-- Add a **Consultation Log** section documenting:
-  - Key feedback received
-  - Changes made in response
-  - Any feedback intentionally not incorporated (with reasoning)
-
-### 7. Human Review
-
-After consultation feedback is incorporated:
-- Present the spec for human review
-- Wait for approval or change requests
-- If changes requested, make them and proceed to Step 8
-
-### 8. MANDATORY: Second Consultation (After Human Feedback)
+### 6. Finalize
 
-After incorporating human feedback:
-
-```bash
-# Run consultations again (REQUIRED)
-consult --model gemini spec {{project_id}} &
-consult --model codex spec {{project_id}} &
-wait
-```
-
-- Update Consultation Log with new feedback
-- Incorporate changes
-- Prepare final spec for approval
+After completing the spec draft, signal completion. Porch will run 3-way consultation (Gemini, Codex, Claude) automatically via the verify step. If reviewers request changes, you'll be respawned with their feedback.
 
 ## Output
 
@@ -129,8 +89,6 @@ Create or update the specification file at `codev/specs/{{project_id}}-{{title}}
 - Plan: `codev/plans/{{project_id}}-{{title}}.md`
 - Review: `codev/reviews/{{project_id}}-{{title}}.md`
 
-Include a **Consultation Log** section in the spec documenting all consultation feedback.
-
 ## Signals
 
 Emit appropriate signals based on your progress:
@@ -152,15 +110,6 @@ Emit appropriate signals based on your progress:
   <signal>SPEC_DRAFTED</signal>
   ```
 
-- After incorporating consultation feedback:
-  ```
-  <signal>CONSULTATION_INCORPORATED</signal>
-  ```
-
-- After final spec is ready for human approval:
-  ```
-  <signal>SPEC_READY_FOR_APPROVAL</signal>
-  ```
 
 ## Commit Cadence
 
@@ -177,15 +126,13 @@ git add codev/specs/{{project_id}}-{{title}}.md
 
 ## Important Notes
 
-1. **Consultation is MANDATORY** - Cannot skip GPT-5 + Gemini reviews
-2. **Be thorough** - A good spec prevents implementation problems
+1. **Be thorough** - A good spec prevents implementation problems
 3. **Be specific** - Vague specs lead to wrong implementations
 4. **Include examples** - Concrete examples clarify intent
-5. **Document consultations** - Maintain the Consultation Log section
 
 ## What NOT to Do
 
-- Don't skip consultations (they are BLOCKING)
+- Don't run `consult` commands yourself (porch handles consultations)
 - Don't include implementation details (that's for the Plan phase)
 - Don't estimate time (AI makes time estimates meaningless)
 - Don't start coding (you're in Specify, not Implement)

package/skeleton/protocols/{spider → spir}/protocol.json

@@ -1,7 +1,7 @@
 {
   "$schema": "../../protocol-schema.json",
-  "name": "spider",
-  "alias": "spir",
+  "name": "spir",
+  "alias": "spider",
   "version": "2.2.0",
   "description": "SPIR: Specify → Plan → Implement → Review with build-verify cycles",
   "input": {

package/skeleton/protocols/{spider → spir}/protocol.md

@@ -1,7 +1,5 @@
-# SPIR Protocol (formerly SPIDER)
+# SPIR Protocol
 
-> **Also known as**: SPIDER (legacy name)
->
 > **SPIR** = **S**pecify → **P**lan → **I**mplement → **R**eview
 >
 > Each phase has one build-verify cycle with 3-way consultation.
@@ -20,17 +18,17 @@
 ### Multi-Agent Consultation (ENABLED BY DEFAULT)
 
 **DEFAULT BEHAVIOR:**
-Multi-agent consultation is **ENABLED BY DEFAULT** when using SPIDER protocol.
+Multi-agent consultation is **ENABLED BY DEFAULT** when using SPIR protocol.
 
 **DEFAULT AGENTS:**
 - **GPT-5 Codex**: Primary reviewer for architecture, feasibility, and code quality
 - **Gemini Pro**: Secondary reviewer for completeness, edge cases, and alternative approaches
 
 **DISABLING CONSULTATION:**
-To run SPIDER without consultation, say "without consultation" when starting work.
+To run SPIR without consultation, say "without consultation" when starting work.
 
 **CUSTOM AGENTS:**
-The user can specify different agents by saying: "use SPIDER with consultation from [agent1] and [agent2]"
+The user can specify different agents by saying: "use SPIR with consultation from [agent1] and [agent2]"
 
 **CONSULTATION BEHAVIOR:**
 - DEFAULT: MANDATORY consultation with GPT-5 and Gemini Pro at EVERY checkpoint
@@ -596,12 +594,12 @@ Implements bcrypt-based password hashing with configurable rounds
 
 ### Branch Naming
 ```
-spider/####-<spec-name>/<phase-name>
+spir/####-<spec-name>/<phase-name>
 ```
 
 Example:
 ```
-spider/0001-user-authentication/database-schema
+spir/0001-user-authentication/database-schema
 ```
 
 

package/skeleton/protocols/{spider → spir}/templates/review.md

@@ -106,7 +106,7 @@
 
 ## Methodology Feedback
 
-### SP(IDE)R Protocol Effectiveness
+### SPIR Protocol Effectiveness
 - **Specification Phase**: [Was it thorough enough? Too detailed?]
 - **Planning Phase**: [Were estimates accurate? Phases well-sized?]
 - **Implementation Loop**: [Did IDE cycle work well?]

package/skeleton/protocols/tick/builder-prompt.md

@@ -22,7 +22,7 @@ You are running in STRICT mode. This means:
 ## Protocol
 Follow the TICK protocol: `codev/protocols/tick/protocol.md`
 
-TICK is for amendments to existing SPIDER specifications. You will:
+TICK is for amendments to existing SPIR specifications. You will:
 1. Identify the target spec to amend
 2. Update the spec with the amendment
 3. Update the plan

package/skeleton/protocols/tick/protocol.md

@@ -3,16 +3,16 @@
 
 ## Overview
 
-TICK is an **amendment workflow** for existing SPIDER specifications. Rather than creating new standalone specs, TICK modifies existing spec and plan documents in-place, tracking changes in an "Amendments" section.
+TICK is an **amendment workflow** for existing SPIR specifications. Rather than creating new standalone specs, TICK modifies existing spec and plan documents in-place, tracking changes in an "Amendments" section.
 
-**Core Principle**: TICK is for *refining* existing specs. SPIDER is for *creating* new specs.
+**Core Principle**: TICK is for *refining* existing specs. SPIR is for *creating* new specs.
 
-**Key Insight**: TICKs are not small SPIDERs - they're amendments to existing SPIDERs. This eliminates the "TICK vs SPIDER" decision problem and keeps related work together.
+**Key Insight**: TICKs are not small SPIRs - they're amendments to existing SPIRs. This eliminates the "TICK vs SPIR" decision problem and keeps related work together.
 
 ## When to Use TICK
 
 ### Use TICK when:
-- Making **amendments to an existing SPIDER spec** that is already `integrated`
+- Making **amendments to an existing SPIR spec** that is already `integrated`
 - Small scope (< 300 lines of new/changed code)
 - Requirements are clear and well-defined
 - No fundamental architecture changes
@@ -23,7 +23,7 @@ TICK is an **amendment workflow** for existing SPIDER specifications. Rather tha
   - Utility function additions to existing modules
   - Refactoring within an existing feature
 
-### Use SPIDER instead when:
+### Use SPIR instead when:
 - Creating a **new feature from scratch** (no existing spec to amend)
 - Major architecture changes (scope too large for amendment)
 - Unclear requirements needing exploration
@@ -31,8 +31,8 @@ TICK is an **amendment workflow** for existing SPIDER specifications. Rather tha
 - Multiple stakeholders need alignment
 
 ### Cannot Use TICK when:
-- No relevant SPIDER spec exists (create a new SPIDER spec instead)
-- Target spec is not yet `integrated` (complete the SPIDER cycle first)
+- No relevant SPIR spec exists (create a new SPIR spec instead)
+- Target spec is not yet `integrated` (complete the SPIR cycle first)
 
 ## Amendment Workflow
 
@@ -162,9 +162,9 @@ The format `[TICK ####-NNN]` identifies:
 - `####`: Parent spec number (e.g., 0002)
 - `NNN`: TICK amendment number (e.g., 001, 002, 003)
 
-## Key Differences from SPIDER
+## Key Differences from SPIR
 
-| Aspect | SPIDER | TICK |
+| Aspect | SPIR | TICK |
 |--------|--------|------|
 | Purpose | Create new features | Amend existing features |
 | File creation | Creates new spec/plan/review | Modifies spec/plan, creates review |
@@ -178,16 +178,16 @@ The format `[TICK ####-NNN]` identifies:
 
 ```
 Is there an existing spec to amend?
-├── NO → Use SPIDER (create new spec)
+├── NO → Use SPIR (create new spec)
 └── YES → Is it integrated?
-    ├── NO → Complete SPIDER cycle first
+    ├── NO → Complete SPIR cycle first
     └── YES → Is the change small (<300 LOC)?
         ├── YES → Use TICK (amend existing spec)
-        └── NO → Use SPIDER (scope too large)
+        └── NO → Use SPIR (scope too large)
 ```
 
 **Mental Model**:
-- SPIDER = Create new feature from scratch
+- SPIR = Create new feature from scratch
 - TICK = Refine/extend existing feature
 
 ## Example TICK Workflow
@@ -251,7 +251,7 @@ Existing standalone TICK projects (created before this protocol change) are gran
 1. **Single source of truth**: Spec file shows complete feature evolution
 2. **Clear history**: Amendments section documents all changes chronologically
 3. **Reduced fragmentation**: Related work stays together
-4. **Simpler mental model**: "New vs amendment" is clearer than "SPIDER vs TICK"
+4. **Simpler mental model**: "New vs amendment" is clearer than "SPIR vs TICK"
 5. **Preserved context**: Looking at a spec shows all refinements
 
 ## Limitations
@@ -264,14 +264,14 @@ Existing standalone TICK projects (created before this protocol change) are gran
 ## Best Practices
 
 1. **Verify spec is integrated**: Never TICK a spec that isn't complete
-2. **Keep TICKs small**: If scope grows, consider new SPIDER spec
+2. **Keep TICKs small**: If scope grows, consider new SPIR spec
 3. **Clear summaries**: Amendment entries should be self-explanatory
 4. **Test before review**: Always test functionality before presenting
 5. **Honest documentation**: Document all deviations in review
 
 ## Templates
 
-TICK uses the standard SPIDER templates with amendments sections:
-- Spec template: `codev/protocols/spider/templates/spec.md` (includes Amendments section)
-- Plan template: `codev/protocols/spider/templates/plan.md` (includes Amendment History section)
+TICK uses the standard SPIR templates with amendments sections:
+- Spec template: `codev/protocols/spir/templates/spec.md` (includes Amendments section)
+- Plan template: `codev/protocols/spir/templates/plan.md` (includes Amendment History section)
 - Review template: `codev/protocols/tick/templates/review.md` (TICK-specific)

package/skeleton/protocols/tick/templates/review.md

@@ -77,7 +77,7 @@
 
 ## TICK Protocol Feedback
 - **Autonomous execution**: [Worked well / Issues encountered]
-- **Single-phase approach**: [Appropriate / Should have used SPIDER]
+- **Single-phase approach**: [Appropriate / Should have used SPIR]
 - **Speed vs quality trade-off**: [Balanced / Too fast / Too slow]
 - **End-only consultation**: [Caught issues / Missed opportunities]
 

package/skeleton/resources/commands/overview.md

@@ -91,7 +91,7 @@ Agent Farm is configured via `af-config.json` at the project root. Created durin
 
 ## Related Documentation
 
-- [SPIDER Protocol](../protocols/spider/protocol.md) - Multi-phase development workflow
+- [SPIR Protocol](../protocols/spir/protocol.md) - Multi-phase development workflow
 - [TICK Protocol](../protocols/tick/protocol.md) - Fast amendment workflow
 - [Architect Role](../roles/architect.md) - Architect responsibilities
 - [Builder Role](../roles/builder.md) - Builder responsibilities