@cluesmith/codev 2.0.0-rc.7 → 2.0.0-rc.71

package/skeleton/protocols/spider/prompts/defend.md

@@ -1,215 +0,0 @@
-# DEFEND Phase Prompt
-
-You are executing the **DEFEND** phase of the SPIDER protocol.
-
-## Your Goal
-
-Write comprehensive tests that guard the implementation against regressions and verify correct behavior.
-
-## Context
-
-- **Project ID**: {{project_id}}
-- **Project Title**: {{title}}
-- **Current State**: {{current_state}}
-- **Plan Phase**: {{plan_phase}} (if applicable)
-- **Spec File**: `codev/specs/{{project_id}}-{{title}}.md`
-- **Plan File**: `codev/plans/{{project_id}}-{{title}}.md`
-
-## Consultation Context
-
-**Defend is the last phase before consultation.** After tests pass:
-- You will proceed to Evaluate
-- Evaluate will run multi-agent consultation (GPT-5 Codex + Gemini Pro)
-- Only after consultation approval will the phase be committed
-
-Write thorough tests knowing they will be reviewed.
-
-## Prerequisites
-
-Before writing tests, verify:
-1. Implementation phase is complete
-2. Build passes
-3. You understand what the code is supposed to do
-4. You know the success criteria from the spec
-
-## Process
-
-### 1. Analyze What to Test
-
-Review the implementation and identify:
-- **Core functionality** - The main purpose of the code
-- **Edge cases** - Boundary conditions, empty inputs, etc.
-- **Error conditions** - Invalid inputs, failure scenarios
-- **Integration points** - How components work together
-
-### 2. Write Unit Tests
-
-For each function/method:
-- Test the happy path (normal operation)
-- Test edge cases (empty, null, boundary values)
-- Test error conditions (invalid input, failures)
-
-**Unit Test Principles**:
-- Test behavior, not implementation details
-- One assertion focus per test (can have multiple asserts if related)
-- Clear test names that describe what's being tested
-- Fast execution (no external dependencies)
-
-### 3. Write Integration Tests
-
-For feature flows:
-- Test components working together
-- Test realistic usage scenarios
-- Test the success criteria from the spec
-
-**Integration Test Principles**:
-- Use real implementations for internal boundaries
-- Only mock external dependencies (APIs, databases, file system)
-- Cover critical user paths
-- Test end-to-end scenarios where possible
-
-### 4. Avoid Overmocking
-
-**DO**:
-- Mock external APIs and services
-- Mock file system for isolation
-- Mock time-dependent operations
-- Use real implementations for internal modules
-
-**DON'T**:
-- Mock the system under test
-- Mock internal function calls
-- Create mocks that mirror implementation details
-- Write tests that break when you refactor
-
-### 5. Test Environment Isolation (CRITICAL)
-
-**NEVER touch real $HOME directories in tests.** Use XDG sandboxing:
-
-```bash
-# In test setup
-export XDG_CONFIG_HOME="$TEST_PROJECT/.xdg/config"
-export XDG_DATA_HOME="$TEST_PROJECT/.xdg/data"
-export XDG_CACHE_HOME="$TEST_PROJECT/.xdg/cache"
-export HOME="$TEST_PROJECT/.xdg/home"
-```
-
-**Test Isolation Principles**:
-- Each test should be hermetic (no side effects on user environment)
-- Use temporary directories that are cleaned up after tests
-- Use failing shims instead of removing tools from PATH
-- Never write to actual config directories (~/.config, etc.)
-
-### 6. Run All Tests
-
-```bash
-npm test           # Run all tests
-npm test -- --coverage  # With coverage report
-```
-
-Verify:
-- All new tests pass
-- All existing tests still pass
-- Coverage hasn't decreased
-
-### 6. Fix Failing Tests
-
-If tests fail:
-1. Determine if it's a test bug or implementation bug
-2. If implementation bug → return to Implement phase
-3. If test bug → fix the test
-4. Re-run all tests
-
-## Output
-
-- Test files covering the implementation
-- All tests passing
-- No reduction in code coverage
-
-## Signals
-
-Emit appropriate signals based on your progress:
-
-- After tests are written and passing:
-  ```
-  <signal>TESTS_WRITTEN</signal>
-  ```
-
-- If implementation bugs are found:
-  ```
-  <signal>IMPLEMENTATION_BUG:description</signal>
-  ```
-  (This signals return to Implement phase)
-
-- If blocked:
-  ```
-  <signal>BLOCKED:reason</signal>
-  ```
-
-## Test File Organization
-
-Follow project conventions. Common patterns:
-
-```
-src/
-  auth/
-    login.ts
-tests/
-  auth/
-    login.test.ts
-```
-
-or
-
-```
-src/
-  auth/
-    login.ts
-    login.test.ts  (co-located)
-```
-
-## Test Naming Convention
-
-Use descriptive names that explain the scenario:
-
-```typescript
-// Good
-describe('login', () => {
-  it('returns user data on valid credentials', () => {...})
-  it('throws AuthError on invalid password', () => {...})
-  it('locks account after 5 failed attempts', () => {...})
-})
-
-// Bad
-describe('login', () => {
-  it('works', () => {...})
-  it('test1', () => {...})
-  it('should work correctly', () => {...})
-})
-```
-
-## Important Notes
-
-1. **Tests are documentation** - They show how code should be used
-2. **Test behavior, not implementation** - Tests should survive refactoring
-3. **Prefer integration over unit** - When testing complex flows
-4. **Keep tests fast** - Slow tests get skipped
-5. **One test file per source file** - Easy to find related tests
-
-## What NOT to Do
-
-- Don't skip edge cases ("I'll test that later")
-- Don't mock everything (leads to brittle tests)
-- Don't test private implementation details
-- Don't write tests that pass for wrong reasons
-- Don't leave commented-out tests
-- Don't touch real $HOME or user config directories in tests
-- Don't use `git add .` or `git add -A` when you do commit (security risk)
-
-## Coverage Guidelines
-
-Aim for:
-- 80%+ line coverage for new code
-- 100% coverage of critical paths (auth, payments, etc.)
-- Every public function has at least one test
-- Every error condition has a test

package/skeleton/protocols/spider/prompts/evaluate.md

@@ -1,241 +0,0 @@
-# EVALUATE Phase Prompt
-
-You are executing the **EVALUATE** phase of the SPIDER protocol.
-
-## Your Goal
-
-Verify the implementation fully satisfies the phase requirements, run mandatory multi-agent consultation, and then commit the completed phase.
-
-## CRITICAL: Multi-Agent Consultation is MANDATORY
-
-**DO NOT COMMIT without consultation approval.** This is a BLOCKING requirement.
-
-The evaluation process is:
-1. Verify implementation and tests
-2. Run multi-agent consultation (GPT-5 Codex + Gemini Pro)
-3. Address any feedback
-4. Get human approval
-5. ONLY THEN commit
-
-## Context
-
-- **Project ID**: {{project_id}}
-- **Project Title**: {{title}}
-- **Current State**: {{current_state}}
-- **Plan Phase**: {{plan_phase}} (if applicable)
-- **Spec File**: `codev/specs/{{project_id}}-{{title}}.md`
-- **Plan File**: `codev/plans/{{project_id}}-{{title}}.md`
-
-## Prerequisites
-
-Before evaluating, verify:
-1. Implementation is complete
-2. Tests are written and passing
-3. Build passes
-4. Lint passes (if configured)
-
-## Process
-
-### 1. Functional Evaluation
-
-Check against the spec's success criteria:
-
-- [ ] All acceptance criteria met?
-- [ ] User scenarios work as expected?
-- [ ] Edge cases handled properly?
-- [ ] Error messages are helpful?
-
-### 2. Non-Functional Evaluation
-
-Assess quality attributes:
-
-- [ ] Performance acceptable?
-- [ ] Security standards maintained?
-- [ ] Code is maintainable?
-- [ ] No unnecessary complexity?
-
-### 3. Spec Compliance Check
-
-Compare implementation to specification:
-
-- [ ] Does exactly what spec says (no more, no less)?
-- [ ] Handles all scenarios mentioned in spec?
-- [ ] Matches the expected behavior described?
-
-### 4. Test Quality Check
-
-Verify test coverage:
-
-- [ ] All new code has tests?
-- [ ] Tests cover happy path AND error cases?
-- [ ] No overmocking (tests use real implementations where possible)?
-- [ ] Tests would catch regressions?
-
-### 5. Deviation Analysis
-
-If implementation differs from plan:
-
-- Document what changed and why
-- Assess impact on other phases
-- Update plan if needed
-
-### 6. MANDATORY: Multi-Agent Consultation
-
-**Before committing, run consultation:**
-
-```bash
-# Run consultations in parallel (REQUIRED)
-consult --model gemini --type impl-review spec {{project_id}} &
-consult --model codex --type impl-review spec {{project_id}} &
-wait
-```
-
-- Review ALL feedback from both models
-- Address any issues raised
-- Document feedback in the phase evaluation notes
-
-**If consultants identify issues:**
-- Return to Implement or Defend as needed
-- Fix the issues
-- Re-run consultation
-- Do NOT commit until consultation passes
-
-### 7. Human Review
-
-After consultation feedback is incorporated:
-- Present evaluation summary for human review
-- Wait for approval to commit
-- If changes requested, address them and re-consult if significant
-
-### 8. Phase Commit (After Approval Only)
-
-**CRITICAL**: Only commit after consultation and human approval.
-
-```bash
-# Stage all changes for this phase - NEVER use git add . or git add -A
-git add <specific-files>
-
-# Commit with proper format
-git commit -m "[Spec {{project_id}}][Phase: {{plan_phase}}] feat: <description>"
-```
-
-Commit message format:
-- `[Spec XXXX][Phase: name] feat:` for new features
-- `[Spec XXXX][Phase: name] fix:` for bug fixes
-- `[Spec XXXX][Phase: name] refactor:` for refactoring
-
-### 9. Update Plan Status
-
-Mark this phase as complete in the plan document.
-
-## Output
-
-- Completed evaluation checklist
-- Phase committed to git
-- Plan updated with phase status
-
-## Signals
-
-Emit appropriate signals based on your progress:
-
-- After initial evaluation passes (before consultation):
-  ```
-  <signal>EVALUATION_PASSED</signal>
-  ```
-
-- After consultation feedback is incorporated:
-  ```
-  <signal>CONSULTATION_INCORPORATED</signal>
-  ```
-
-- After human approves and commit is complete:
-  ```
-  <signal>EVALUATION_COMPLETE</signal>
-  ```
-
-- If evaluation reveals spec non-compliance:
-  ```
-  <signal>SPEC_VIOLATION:description</signal>
-  ```
-  (Signals return to Implement)
-
-- If tests reveal bugs:
-  ```
-  <signal>IMPLEMENTATION_BUG:description</signal>
-  ```
-  (Signals return to Implement)
-
-- If consultation identifies issues:
-  ```
-  <signal>CONSULTATION_ISSUES:description</signal>
-  ```
-  (Signals return to Implement or Defend)
-
-- If all plan phases are complete:
-  ```
-  <signal>ALL_PHASES_COMPLETE</signal>
-  ```
-  (Signals transition to Review)
-
-## Evaluation Checklist Template
-
-```markdown
-## Phase Evaluation: {{plan_phase}}
-
-### Functional
-- [ ] Acceptance criteria 1: [status]
-- [ ] Acceptance criteria 2: [status]
-- [ ] Edge cases handled: [status]
-
-### Non-Functional
-- [ ] Performance: [acceptable/needs work]
-- [ ] Security: [reviewed/concerns]
-- [ ] Maintainability: [good/needs refactor]
-
-### Tests
-- [ ] Coverage: [X%]
-- [ ] All tests passing: [yes/no]
-- [ ] Overmocking check: [passed/failed]
-
-### Spec Compliance
-- [ ] Matches spec requirements: [yes/no]
-- [ ] Deviations: [none/list them]
-
-### Commit
-- [ ] Changes staged
-- [ ] Commit created: [hash]
-- [ ] Plan updated
-```
-
-## Important Notes
-
-1. **Consultation is MANDATORY** - Cannot skip GPT-5 + Gemini reviews
-2. **Be honest** - If something isn't right, fix it before committing
-3. **Don't skip the checklist** - It catches issues before they compound
-4. **Atomic commits** - One commit per phase, not multiple
-5. **Update the plan** - Mark phase status after commit
-6. **Verify the commit** - `git log --oneline -1` should show your commit
-
-## What NOT to Do
-
-- Don't commit without consultation approval (BLOCKING)
-- Don't commit if tests are failing
-- Don't commit if build is broken
-- Don't skip the spec compliance check
-- Don't commit multiple phases together
-- Don't proceed to next phase without committing
-- Don't use `git add .` or `git add -A` (security risk)
-
-## Handling Failures
-
-**If spec compliance fails**:
-Return to Implement, fix the issue, re-run Defend, then Evaluate again.
-
-**If tests fail**:
-Return to Implement to fix bugs, or Defend to fix tests.
-
-**If build fails**:
-Return to Implement to fix build errors.
-
-**If you discover a spec problem**:
-Signal `BLOCKED` and describe the spec issue. The Architect may need to update the spec.

package/skeleton/protocols/spider/prompts/implement.md

@@ -1,149 +0,0 @@
-# IMPLEMENT Phase Prompt
-
-You are executing the **IMPLEMENT** phase of the SPIDER protocol.
-
-## Your Goal
-
-Write clean, well-structured code that implements the current plan phase.
-
-## Context
-
-- **Project ID**: {{project_id}}
-- **Project Title**: {{title}}
-- **Current State**: {{current_state}}
-- **Plan Phase**: {{plan_phase}} (if applicable)
-- **Spec File**: `codev/specs/{{project_id}}-{{title}}.md`
-- **Plan File**: `codev/plans/{{project_id}}-{{title}}.md`
-
-## Consultation Context
-
-**Implementation does NOT require consultation checkpoints** - that happens after Defend.
-
-However, you should be aware:
-- Spec and Plan have already been reviewed by GPT-5 Codex and Gemini Pro
-- After you complete Implement + Defend, your work will be reviewed
-- Implementation must strictly follow the approved spec and plan
-
-## Prerequisites
-
-Before implementing, verify:
-1. Previous phase (if any) is committed to git
-2. You've read the plan phase you're implementing
-3. You understand the success criteria for this phase
-4. Dependencies from earlier phases are available
-
-## Process
-
-### 1. Review the Plan Phase
-
-Read the current phase in the plan:
-- What is the objective?
-- What files need to be created/modified?
-- What are the success criteria?
-- What dependencies exist?
-
-### 2. Set Up
-
-- Verify you're on the correct branch
-- Check that previous phase is committed: `git log --oneline -5`
-- Ensure build passes before starting: `npm run build` (or equivalent)
-
-### 3. Implement
-
-Write the code following these principles:
-
-**Code Quality Standards**:
-- Self-documenting code (clear names, obvious structure)
-- No commented-out code
-- No debug prints in final code
-- Explicit error handling
-- Follow project style guide
-
-**Implementation Approach**:
-- Work on one file at a time
-- Make small, incremental changes
-- Test as you go (manual verification is fine here)
-- Document complex logic with comments
-
-### 4. Self-Review
-
-Before signaling completion:
-- Read through all changes
-- Check for obvious bugs
-- Verify code matches the spec requirements
-- Ensure no accidental debug code
-
-### 5. Build Verification
-
-Run build checks using **project-specific commands**:
-
-```bash
-# Check package.json scripts or Makefile for actual commands
-# Common patterns:
-npm run build      # Node.js/TypeScript projects
-npm run typecheck  # TypeScript type checking
-npm run lint       # Linting (ESLint, etc.)
-cargo build        # Rust projects
-go build ./...     # Go projects
-make build         # Projects using Makefiles
-```
-
-**Important**: Don't assume `npm run build` exists. Check `package.json` or equivalent first.
-
-Fix any errors before proceeding.
-
-## Output
-
-- Modified/created source files as specified in the plan phase
-- All build checks passing
-- Code ready for the Defend (testing) phase
-
-## Signals
-
-Emit appropriate signals based on your progress:
-
-- After implementation is complete and builds pass:
-  ```
-  <signal>PHASE_IMPLEMENTED</signal>
-  ```
-
-- If you encounter a blocker:
-  ```
-  <signal>BLOCKED:reason goes here</signal>
-  ```
-
-- If you need spec/plan clarification:
-  ```
-  <signal>NEEDS_CLARIFICATION:specific question</signal>
-  ```
-
-## Important Notes
-
-1. **Follow the plan** - Implement what's specified, not more
-2. **Don't over-engineer** - Simplest solution that works
-3. **Don't skip error handling** - But don't go overboard either
-4. **Keep changes focused** - Only touch files in this phase
-5. **Build must pass** - Don't proceed if build fails
-
-## What NOT to Do
-
-- Don't write tests yet (that's Defend phase)
-- Don't modify files outside this phase's scope
-- Don't add features not in the spec
-- Don't leave TODO comments for later (fix now or note as blocker)
-- Don't commit yet (that happens after Defend + Evaluate)
-- Don't use `git add .` or `git add -A` when you do commit (security risk)
-
-## Handling Problems
-
-**If the plan is unclear**:
-Signal `NEEDS_CLARIFICATION` with your specific question.
-
-**If you discover the spec is wrong**:
-Signal `BLOCKED` and explain the issue. The Architect may need to update the spec.
-
-**If a dependency is missing**:
-Signal `BLOCKED` with details about what's missing.
-
-**If build fails and you can't fix it**:
-Signal `BLOCKED` with the error message.