@cluesmith/codev 2.0.2 → 2.0.6

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@cluesmith/codev",
-  "version": "2.0.2",
+  "version": "2.0.6",
   "description": "Codev CLI - AI-assisted software development framework",
   "type": "module",
   "bin": {
@@ -36,10 +36,13 @@
   "dependencies": {
     "@anthropic-ai/claude-agent-sdk": "^0.2.41",
     "@google/genai": "^1.0.0",
+    "@openai/codex-sdk": "^0.101.0",
+    "@types/http-proxy": "^1.17.17",
     "better-sqlite3": "^12.5.0",
     "chalk": "^5.3.0",
     "commander": "^12.1.0",
     "glob": "^11.0.0",
+    "http-proxy": "^1.18.1",
     "js-yaml": "^4.1.0",
     "node-pty": "^1.1.0",
     "open": "^10.1.0",

package/skeleton/.claude/skills/af/SKILL.md

@@ -28,13 +28,13 @@ af dash open               # Open dashboard in browser
 ## Builder Management
 
 ```bash
-af spawn -p 0003           # Spawn builder for spec (strict mode, default)
-af spawn --soft -p 0003    # Spawn builder (soft mode)
+af spawn -p 3           # Spawn builder for spec (strict mode, default)
+af spawn --soft -p 3    # Spawn builder (soft mode)
 af spawn --issue 42        # Spawn builder for a bugfix
-af spawn -p 0003 --resume  # Resume builder in existing worktree
+af spawn -p 3 --resume  # Resume builder in existing worktree
 af status                  # Check all builder status
-af cleanup --project 0003  # Clean up builder worktree (safe)
-af cleanup --project 0003 -f  # Force cleanup
+af cleanup --project 3  # Clean up builder worktree (safe)
+af cleanup --project 3 -f  # Force cleanup
 ```
 
 ### Resuming Builders
@@ -43,10 +43,10 @@ When a builder's Claude process dies but the worktree and porch state survive,
 use `--resume` to restart it without recreating the worktree:
 
 ```bash
-af spawn -p 0003 --resume
+af spawn -p 3 --resume
 ```
 
-This reuses the existing `.builders/0003` worktree, creates a fresh terminal
+This reuses the existing `.builders/3` worktree, creates a fresh terminal
 session registered with the Tower (so it appears in the dashboard), and lets
 porch pick up from whatever phase the builder was in. Works with all spawn
 modes: `-p`, `--issue`, `--task`, `--protocol`, `--worktree`.

package/skeleton/.claude/skills/consult/SKILL.md

@@ -77,5 +77,5 @@ Roles are markdown files in `codev/roles/`. Create your own by adding `.md` file
 
 - The `-m` flag is **required** — `consult pr 42` will fail without it
 - PR numbers are GitHub PR numbers, not spec numbers
-- Spec/plan numbers match the `0042` prefix in filenames (pass just `42`, not `0042`)
+- Spec/plan numbers match the `42` prefix in filenames (pass just `42`, not `42`)
 - General queries must be **quoted**: `consult -m gemini general "your question here"`

package/skeleton/builders.md

@@ -18,8 +18,8 @@ Track active builder agents here. Update manually or via `architect status`.
 <!-- Add builders below as they are spawned -->
 
 <!-- Example:
-## Builder 0003: Feature Name
-- **Branch**: builder/0003-feature-name
+## Builder 3: Feature Name
+- **Branch**: builder/3-feature-name
 - **Port**: 7681
 - **Status**: implementing
 - **Phase**: 2/4

package/skeleton/maintain/.gitkeep

@@ -1,2 +1,2 @@
 # Maintenance run files go here
-# Files are numbered: 0001-maintenance.md, 0002-maintenance.md, etc.
+# Files are numbered: 1-maintenance.md, 2-maintenance.md, etc.

package/skeleton/porch/prompts/specify.md

@@ -10,7 +10,7 @@ Write a detailed specification for the assigned project. The spec must be comple
 
 Read these files to understand the task:
 1. `codev/status/{project-id}-*.md` - Current project state and any notes
-2. `codev/projectlist.md` - Project entry with initial description
+2. The GitHub Issue for this project (if available)
 3. Any existing context files mentioned in the project entry
 
 ## Output Requirements

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

@@ -54,21 +54,32 @@ consult --model claude pr <PR_NUMBER> &
 
 All three should run in the background (`run_in_background: true`).
 
-### 3. Address Feedback
+### 3. Wait for Results and Address Feedback
 
-Review the consultation results:
+**DO NOT proceed to step 4 until ALL THREE consultations have returned results.**
+
+Wait for each background consultation to complete, then read the results:
+- Use `TaskOutput` (with `block: true`) to retrieve each consultation result
+- Record each model's verdict (APPROVE or REQUEST_CHANGES)
 - Fix any issues identified by reviewers
 - Push updates to the PR branch
 - Re-run CMAP if substantial changes were made
 
+You must have three concrete verdicts (e.g., "gemini: APPROVE, codex: APPROVE, claude: APPROVE") before continuing.
+
 ### 4. Notify Architect
 
-After CMAP review is complete and feedback is addressed, notify the architect:
+**DO NOT send this notification until you have all three CMAP verdicts from step 3.**
+
+Send a **single** notification that includes the PR link and each model's verdict:
 
 ```bash
-af send architect "PR #<number> ready for review (fixes issue #{{issue.number}})"
+af send architect "PR #<number> ready for review (fixes issue #{{issue.number}}). CMAP: gemini=<APPROVE|REQUEST_CHANGES>, codex=<APPROVE|REQUEST_CHANGES>, claude=<APPROVE|REQUEST_CHANGES>"
 ```
 
+**This is the only notification you send.** After this, your work is done — the architect
+takes it from here (reviews, merges, cleans up).
+
 ## Signals
 
 When PR is created and reviews are complete:

package/skeleton/protocols/experiment/protocol.md

@@ -16,13 +16,13 @@ Disciplined experimentation: Each experiment gets its own directory with `notes.
 
 ```
 experiments/
-├── 0001_descriptive_name/
+├── 1_descriptive_name/
 │   ├── notes.md           # Goal, code, results
 │   ├── experiment.py      # Your experiment code
 │   └── data/
 │       ├── input/         # Input data
 │       └── output/        # Results, plots, etc.
-└── 0002_another_experiment/
+└── 2_another_experiment/
     ├── notes.md
     └── ...
 ```
@@ -33,8 +33,8 @@ experiments/
 
 ```bash
 # Create numbered directory
-mkdir -p experiments/0001_experiment_name
-cd experiments/0001_experiment_name
+mkdir -p experiments/1_experiment_name
+cd experiments/1_experiment_name
 
 # Initialize notes.md from template
 cp codev/protocols/experiment/templates/notes.md notes.md
@@ -81,8 +81,8 @@ Update `notes.md` with:
 ### 6. Commit
 
 ```bash
-git add experiments/0001_experiment_name/
-git commit -m "[Experiment 0001] Brief description of findings"
+git add experiments/1_experiment_name/
+git commit -m "[Experiment 1] Brief description of findings"
 ```
 
 ## notes.md Template
@@ -152,8 +152,8 @@ Example spec reference:
 ```markdown
 ## Background
 
-Experiment 0005 validated that [approach] achieves [results].
-See: experiments/0005_validation_test/notes.md
+Experiment 5 validated that [approach] achieves [results].
+See: experiments/5_validation_test/notes.md
 ```
 
 ### Experiment → TICK
@@ -164,22 +164,22 @@ For small, validated changes discovered during experimentation:
 ## Numbering Convention
 
 Use four-digit sequential numbering (consistent with project list):
-- `0001_`, `0002_`, `0003_`...
+- `1_`, `2_`, `3_`...
 - Shared sequence across all experiments
 - Descriptive name after the number (snake_case)
 
 Examples:
-- `0001_api_response_caching`
-- `0002_model_comparison`
-- `0003_performance_baseline`
+- `1_api_response_caching`
+- `2_model_comparison`
+- `3_performance_baseline`
 
 ## Git Workflow
 
 ### Commits
 ```
-[Experiment 0001] Initial setup and goal
-[Experiment 0001] Add baseline measurements
-[Experiment 0001] Complete - caching improves latency 40%
+[Experiment 1] Initial setup and goal
+[Experiment 1] Add baseline measurements
+[Experiment 1] Complete - caching improves latency 40%
 ```
 
 ### When to Commit
@@ -196,7 +196,7 @@ Examples:
 ## Example Experiment
 
 ```
-experiments/0001_caching_strategy/
+experiments/1_caching_strategy/
 ├── notes.md
 ├── benchmark.py
 ├── cache_test.py
@@ -210,7 +210,7 @@ experiments/0001_caching_strategy/
 
 **notes.md excerpt:**
 ```markdown
-# Experiment 0001: Caching Strategy Evaluation
+# Experiment 1: Caching Strategy Evaluation
 
 **Status**: Complete
 

package/skeleton/protocols/maintain/prompts/audit.md

@@ -56,7 +56,7 @@ grep -E "src/|packages/" codev/resources/arch.md | head -20
 
 ### 5. Create Audit Report
 
-Create a maintenance run file: `codev/maintain/NNNN.md`
+Create a maintenance run file: `codev/maintain/NNN.md`
 
 Document:
 - Dead code identified (with file paths)
@@ -66,7 +66,7 @@ Document:
 
 Use the template structure:
 ```markdown
-# Maintenance Run NNNN
+# Maintenance Run NNN
 
 **Date**: YYYY-MM-DD
 **Base Commit**: <commit-hash>

package/skeleton/protocols/maintain/prompts/sync.md

@@ -47,7 +47,7 @@ Extract actionable lessons:
 Format:
 ```markdown
 ## [Topic]
-- [From NNNN] Lesson description
+- [From NNN] Lesson description
 ```
 
 ### 3. Sync CLAUDE.md with AGENTS.md

package/skeleton/protocols/maintain/prompts/verify.md

@@ -63,7 +63,7 @@ Recommended focus areas for next run:
 ```bash
 git push origin HEAD
 
-gh pr create --title "[Maintain] Codebase maintenance run NNNN" --body "$(cat <<'EOF'
+gh pr create --title "[Maintain] Codebase maintenance run NNN" --body "$(cat <<'EOF'
 ## Summary
 
 - Dead code removal

package/skeleton/protocols/maintain/protocol.md

@@ -57,8 +57,8 @@ Each maintenance run creates a numbered file in `codev/maintain/`:
 
 ```
 codev/maintain/
-├── 0001.md
-├── 0002.md
+├── 1.md
+├── 2.md
 └── ...
 ```
 
@@ -111,8 +111,7 @@ ruff check --select F401   # Find unused imports
 
 | Task | Parallelizable | Human Review? | Description |
 |------|----------------|---------------|-------------|
-| Update projectlist.md status | Yes | No | Update project statuses |
-| Archive terminal projects | Yes | No | Move completed/abandoned to terminal section |
+| Update GitHub Issue statuses | Yes | No | Close completed issues, update labels |
 
 ### Framework Tasks
 
@@ -285,15 +284,15 @@ Extract actionable wisdom from review documents into `codev/resources/lessons-le
 # Lessons Learned
 
 ## Testing
-- [From 0001] Always use XDG sandboxing in tests to avoid touching real $HOME
-- [From 0009] Verify dependencies actually export what you expect
+- [From 1] Always use XDG sandboxing in tests to avoid touching real $HOME
+- [From 9] Verify dependencies actually export what you expect
 
 ## Architecture
-- [From 0008] Single source of truth beats distributed state
-- [From 0031] SQLite with WAL mode handles concurrency better than JSON files
+- [From 8] Single source of truth beats distributed state
+- [From 31] SQLite with WAL mode handles concurrency better than JSON files
 
 ## Process
-- [From 0001] Multi-agent consultation catches issues humans miss
+- [From 1] Multi-agent consultation catches issues humans miss
 ```
 
 ### Sync CLAUDE.md ↔ AGENTS.md

package/skeleton/protocols/maintain/templates/maintenance-run.md

@@ -1,4 +1,4 @@
-# Maintenance Run NNNN
+# Maintenance Run NNN
 
 ## Metadata
 - **Date**: YYYY-MM-DD
@@ -30,7 +30,7 @@ git log --oneline <last-maint-commit>..HEAD
 
 ### Framework
 - [ ] codev update
-- [ ] projectlist.md status updates
+- [ ] GitHub Issue status updates (close completed, update labels)
 
 ## Findings
 

package/skeleton/protocols/spir/protocol.json

@@ -24,7 +24,7 @@
         "models": ["gemini", "codex", "claude"],
         "parallel": true
       },
-      "max_iterations": 7,
+      "max_iterations": 1,
       "on_complete": {
         "commit": true,
         "push": true
@@ -46,7 +46,7 @@
         "models": ["gemini", "codex", "claude"],
         "parallel": true
       },
-      "max_iterations": 7,
+      "max_iterations": 1,
       "on_complete": {
         "commit": true,
         "push": true
@@ -73,7 +73,7 @@
         "models": ["gemini", "codex", "claude"],
         "parallel": true
       },
-      "max_iterations": 7,
+      "max_iterations": 1,
       "on_complete": {
         "commit": true,
         "push": true
@@ -110,7 +110,7 @@
         "models": ["gemini", "codex", "claude"],
         "parallel": true
       },
-      "max_iterations": 7,
+      "max_iterations": 1,
       "on_complete": {
         "commit": true,
         "push": true
@@ -147,7 +147,7 @@
   },
   "defaults": {
     "mode": "strict",
-    "max_iterations": 7,
+    "max_iterations": 1,
     "verify": {
       "models": ["gemini", "codex", "claude"],
       "parallel": true

package/skeleton/protocols/spir/protocol.md

@@ -553,9 +553,9 @@ Execute for each phase in the plan. Each phase follows a build-verify cycle.
 
 ### Specifications and Plans
 Format: `####-descriptive-name.md`
-- Use sequential numbering (0001, 0002, etc.)
+- Use sequential numbering (1, 2, etc.)
 - Same filename in both `specs/` and `plans/` directories
-- Example: `0001-user-authentication.md`
+- Example: `1-user-authentication.md`
 
 ## Status Tracking
 
@@ -578,10 +578,10 @@ For specification/plan documents:
 
 Examples:
 ```
-[Spec 0001] Initial specification draft
-[Spec 0001] Specification with multi-agent review
-[Spec 0001] Specification with user feedback
-[Spec 0001] Final approved specification
+[Spec 1] Initial specification draft
+[Spec 1] Specification with multi-agent review
+[Spec 1] Specification with user feedback
+[Spec 1] Final approved specification
 ```
 
 For implementation:
@@ -593,7 +593,7 @@ For implementation:
 
 Example:
 ```
-[Spec 0001][Phase: user-auth] feat: Add password hashing service
+[Spec 1][Phase: user-auth] feat: Add password hashing service
 
 Implements bcrypt-based password hashing with configurable rounds
 ```
@@ -605,7 +605,7 @@ spir/####-<spec-name>/<phase-name>
 
 Example:
 ```
-spir/0001-user-authentication/database-schema
+spir/1-user-authentication/database-schema
 ```
 
 

package/skeleton/protocols/tick/protocol.md

@@ -50,7 +50,7 @@ TICK is an **amendment workflow** for existing SPIR specifications. Rather than
 **Example**:
 ```
 User: "Use TICK to add password reset to the auth system"
-Agent finds: specs/0002-user-authentication.md (status: integrated)
+Agent finds: specs/2-user-authentication.md (status: integrated)
 Agent determines: Next TICK is TICK-001 (first amendment)
 ```
 
@@ -58,7 +58,7 @@ Agent determines: Next TICK is TICK-001 (first amendment)
 
 **Agent Actions**:
 1. Analyze what needs to change in the spec
-2. Update relevant sections of `specs/####-name.md`:
+2. Update relevant sections of `specs/NNN-name.md`:
    - Problem Statement (if scope expands)
    - Success Criteria (if new criteria added)
    - Solution Approaches (if design changes)
@@ -78,14 +78,14 @@ Agent determines: Next TICK is TICK-001 (first amendment)
    **Plan Changes**:
    - [Phase/steps]: [What was added/modified]
 
-   **Review**: See `reviews/####-name-tick-001.md`
+   **Review**: See `reviews/NNN-name-tick-001.md`
    ```
-4. **COMMIT**: `[TICK ####-NNN] Spec: [description]`
+4. **COMMIT**: `[TICK NNN-NNN] Spec: [description]`
 
 ### Phase 3: Planning Amendment (Autonomous)
 
 **Agent Actions**:
-1. Update `plans/####-name.md` with new implementation steps
+1. Update `plans/NNN-name.md` with new implementation steps
 2. Add/modify phases as needed
 3. Add entry to "Amendment History" section at bottom:
    ```markdown
@@ -95,9 +95,9 @@ Agent determines: Next TICK is TICK-001 (first amendment)
    - [Phase added]: [Description]
    - [Implementation steps]: [What was updated]
 
-   **Review**: See `reviews/####-name-tick-001.md`
+   **Review**: See `reviews/NNN-name-tick-001.md`
    ```
-4. **COMMIT**: `[TICK ####-NNN] Plan: [description]`
+4. **COMMIT**: `[TICK NNN-NNN] Plan: [description]`
 
 ### Phase 4: Implementation (Autonomous)
 
@@ -105,12 +105,12 @@ Agent determines: Next TICK is TICK-001 (first amendment)
 1. Execute implementation steps from the plan
 2. Write code following fail-fast principles
 3. Test functionality
-4. **COMMIT**: `[TICK ####-NNN] Impl: [description]`
+4. **COMMIT**: `[TICK NNN-NNN] Impl: [description]`
 
 ### Phase 5: Review (User Checkpoint)
 
 **Agent Actions**:
-1. Create review document: `reviews/####-name-tick-NNN.md`
+1. Create review document: `reviews/NNN-name-tick-NNN.md`
    - What was amended and why
    - Changes made to spec and plan
    - Implementation challenges
@@ -120,7 +120,7 @@ Agent determines: Next TICK is TICK-001 (first amendment)
    - Focus: Code quality, missed issues, improvements
    - Update review with consultation feedback
 3. **Update Architecture Documentation** (if applicable)
-4. **COMMIT**: `[TICK ####-NNN] Review: [description]`
+4. **COMMIT**: `[TICK NNN-NNN] Review: [description]`
 5. **PRESENT TO USER**: Show summary with consultation insights
 
 **User Actions**:
@@ -130,7 +130,7 @@ Agent determines: Next TICK is TICK-001 (first amendment)
 
 **If Changes Requested**:
 - Agent makes changes
-- Commits: `[TICK ####-NNN] Fixes: [description]`
+- Commits: `[TICK NNN-NNN] Fixes: [description]`
 - Updates review document
 - Repeats until user approval
 
@@ -140,9 +140,9 @@ TICK amendments modify existing files and create new review files:
 
 | File Type | Pattern | Example |
 |-----------|---------|---------|
-| Spec (modified) | `specs/####-name.md` | `specs/0002-user-authentication.md` |
-| Plan (modified) | `plans/####-name.md` | `plans/0002-user-authentication.md` |
-| Review (new) | `reviews/####-name-tick-NNN.md` | `reviews/0002-user-authentication-tick-001.md` |
+| Spec (modified) | `specs/NNN-name.md` | `specs/2-user-authentication.md` |
+| Plan (modified) | `plans/NNN-name.md` | `plans/2-user-authentication.md` |
+| Review (new) | `reviews/NNN-name-tick-NNN.md` | `reviews/2-user-authentication-tick-001.md` |
 
 **Note**: Spec and plan files are modified in-place. Only the review file is new.
 
@@ -151,16 +151,16 @@ TICK amendments modify existing files and create new review files:
 **TICK commits reference the parent spec and TICK number**:
 
 ```
-[TICK 0002-001] Spec: Add password reset feature
-[TICK 0002-001] Plan: Add password reset implementation
-[TICK 0002-001] Impl: Add password reset feature
-[TICK 0002-001] Review: Password reset implementation
-[TICK 0002-001] Fixes: Address review feedback
+[TICK 2-001] Spec: Add password reset feature
+[TICK 2-001] Plan: Add password reset implementation
+[TICK 2-001] Impl: Add password reset feature
+[TICK 2-001] Review: Password reset implementation
+[TICK 2-001] Fixes: Address review feedback
 ```
 
-The format `[TICK ####-NNN]` identifies:
-- `####`: Parent spec number (e.g., 0002)
-- `NNN`: TICK amendment number (e.g., 001, 002, 003)
+The format `[TICK <parent>-<tick>]` identifies:
+- `<parent>`: Parent spec number (e.g., 2)
+- `<tick>`: TICK amendment number (e.g., 001, 002, 003)
 
 ## Key Differences from SPIR
 
@@ -168,7 +168,7 @@ The format `[TICK ####-NNN]` identifies:
 |--------|--------|------|
 | Purpose | Create new features | Amend existing features |
 | File creation | Creates new spec/plan/review | Modifies spec/plan, creates review |
-| Sequential numbering | Gets new number (0001, 0002) | Uses parent's number (0002-001) |
+| Sequential numbering | Gets new number (1, 2) | Uses parent's number (2-001) |
 | Scope | Any size | < 300 lines typically |
 | Prerequisites | None | Existing integrated spec required |
 | User checkpoints | Multiple (spec, plan, phases) | Two (start, end) |
@@ -195,24 +195,24 @@ Is there an existing spec to amend?
 **User**: "Add password reset to the user authentication system"
 
 **Agent**:
-1. **Identify**: Finds `specs/0002-user-authentication.md` (integrated)
+1. **Identify**: Finds `specs/2-user-authentication.md` (integrated)
 2. **Amend Spec** (30 seconds):
    - Updates Success Criteria with password reset requirements
    - Adds TICK-001 entry to Amendments section
-   - Commit: `[TICK 0002-001] Spec: Add password reset feature`
+   - Commit: `[TICK 2-001] Spec: Add password reset feature`
 3. **Amend Plan** (30 seconds):
    - Adds Phase 4: Password Reset Email Service
    - Adds TICK-001 entry to Amendment History
-   - Commit: `[TICK 0002-001] Plan: Add password reset implementation`
+   - Commit: `[TICK 2-001] Plan: Add password reset implementation`
 4. **Implement** (2 minutes):
    - Creates password reset endpoint
    - Implements email service
    - Tests functionality
-   - Commit: `[TICK 0002-001] Impl: Add password reset feature`
+   - Commit: `[TICK 2-001] Impl: Add password reset feature`
 5. **Review** (1 minute):
-   - Creates `reviews/0002-user-authentication-tick-001.md`
+   - Creates `reviews/2-user-authentication-tick-001.md`
    - Runs 3-way consultation (Gemini, Codex, Claude)
-   - Commit: `[TICK 0002-001] Review: Password reset implementation`
+   - Commit: `[TICK 2-001] Review: Password reset implementation`
    - Shows user the completed work
 
 **Total Time**: ~4 minutes for simple amendment
@@ -243,8 +243,8 @@ Existing standalone TICK projects (created before this protocol change) are gran
 **Optional Migration** (if desired):
 1. Identify the "parent spec" the TICK logically extends
 2. Move TICK content into an amendment entry in the parent spec
-3. Archive the standalone files with a note: "Migrated to spec #### as TICK-NNN"
-4. Update projectlist.md to reflect the change
+3. Archive the standalone files with a note: "Migrated to spec NNN as TICK-NNN"
+4. Update the GitHub Issue to reflect the change
 
 ## Benefits