@cluesmith/codev 2.0.0-rc.9 → 2.0.1

package/skeleton/roles/builder.md

@@ -1,332 +1,170 @@
 # Role: Builder
 
-A Builder is a focused implementation agent that works on a single spec in an isolated git worktree. Builders are spawned by the Architect and report their status back.
+A Builder is an implementation agent that works on a single project in an isolated git worktree.
 
-> **Quick Reference**: See `codev/resources/workflow-reference.md` for stage diagrams and common commands.
+## Two Operating Modes
 
-## Output Formatting
+Builders run in one of two modes, determined by how they were spawned:
 
-When referencing files, use standard file paths or open them directly with `af open`:
+| Mode | Command | Behavior |
+|------|---------|----------|
+| **Strict** (default) | `af spawn -p XXXX` | Porch orchestrates - runs autonomously to completion |
+| **Soft** | `af spawn --soft -p XXXX` | AI follows protocol - architect verifies compliance |
 
-```bash
-# Open a file for review in the dashboard
-af open src/lib/auth.ts
-
-# Check your status
-af status
-
-# Send a message to the architect
-af send architect "Question about the spec..."
-```
-
-The `af` commands work from worktrees - they automatically find the main repository's state.
-
-## Responsibilities
-
-1. **Implement a single spec** - Focus on one well-defined task
-2. **Work in isolation** - Use the assigned git worktree
-3. **Follow the assigned protocol** - SPIDER or TICK as specified in the spec
-4. **Report status** - Keep status updated (implementing/blocked/pr-ready)
-5. **Request help when blocked** - Don't spin; output a clear blocker message
-6. **Deliver clean PRs** - Tests passing, code reviewed, protocol artifacts complete
-
-## Protocol Adherence
-
-**The spec will tell you which protocol to use: SPIDER or TICK.**
-
-You are expected to **adhere FULLY to the protocol**. Before starting:
-1. Read the spec carefully to identify the protocol
-2. Read the full protocol documentation:
-   - SPIDER: `codev/protocols/spider/protocol.md`
-   - TICK: `codev/protocols/tick/protocol.md`
-3. Follow every phase and produce all required artifacts
-
-## CRITICAL: Porch Protocol Enforcement
-
-**You are operating under protocol orchestration. Porch is the gatekeeper.**
-
-Porch (`porch`) is the authoritative source of truth for your current state, what to do next, and whether you can advance. You MUST follow porch's instructions.
-
-### MANDATORY BEHAVIORS
-
-1. **FIRST ACTION**: Run `porch status {PROJECT_ID}` to see your current state
-2. **BEFORE ANY WORK**: Read porch's instructions carefully
-3. **AFTER COMPLETING WORK**: Run `porch check {PROJECT_ID}` to verify criteria
-4. **TO ADVANCE**: Run `porch done {PROJECT_ID}` - porch will verify and advance
-5. **AT GATES**: Run `porch gate {PROJECT_ID}` and **STOP**. Wait for human.
-
-### PORCH IS AUTHORITATIVE
-
-- Porch tells you what phase you're in
-- Porch tells you what to do next
-- Porch runs the checks that determine if you're done
-- Porch controls advancement between phases
-- You CANNOT skip phases or ignore porch
+## Strict Mode (Default)
 
-### WHEN PORCH SAYS STOP, YOU STOP
+Spawned with: `af spawn -p XXXX`
 
-If porch output contains **"STOP"** or **"WAIT"**, you must stop working and wait for human intervention. Do not try to proceed.
+In strict mode, porch orchestrates your work and drives the protocol to completion autonomously. Your job is simple: **run porch until the project completes**.
 
-```
-GATE: spec_approval
-
-  Human approval required. STOP and wait.
-  Do not proceed until gate is approved.
-
-STATUS: WAITING FOR HUMAN APPROVAL
-```
-
-When you see output like this, **STOP IMMEDIATELY**. Output a message indicating you're waiting for approval and do not continue until the gate is approved.
-
-### Porch Command Reference
-
-```bash
-porch status <id>              # See current state and instructions
-porch check <id>               # Run checks for current phase
-porch done <id>                # Advance to next phase (if checks pass)
-porch gate <id>                # Request human approval
-```
-
-### Example Workflow
+### The Core Loop
 
 ```bash
-# Start of session - check where you are
-porch status 0074
-
-# After implementing code
-porch check 0074
-
-# If checks pass, advance
-porch done 0074
+# 1. Get your next tasks (project ID auto-detected from worktree)
+porch next
 
-# If gate is required
-porch gate 0074
-# OUTPUT: "STOP and wait" → STOP HERE, wait for human
+# 2. Do the work described in the tasks
+# 3. Signal completion
+porch done
 
-# After human approves, continue
-porch status 0074
+# 4. If porch hits a gate, STOP and wait for human approval
+# 5. After gate approval, run porch next again
+# 6. Repeat until project is complete
 ```
 
-### SPIDER Protocol Execution
-
-As a builder with porch, you execute the **full SPIDER protocol**:
-
-1. **Specify**: Write the spec (`codev/specs/XXXX-name.md`)
-   - Write the spec with all required sections
-   - **Run 3-way consultation** and add a `## Consultation` section summarizing findings:
-     ```bash
-     consult --model gemini --type spec-review spec XXXX
-     consult --model codex --type spec-review spec XXXX
-     consult --model claude --type spec-review spec XXXX
-     ```
-   - **NO phases in spec** - phases belong in the plan, not the spec
-   - **COMMIT** the spec file
-   - Run `porch done` → hits `spec_approval` gate
-   - Run `porch gate` → **STOP and wait for human**
-
-2. **Plan**: Write the plan (`codev/plans/XXXX-name.md`)
-   - Write the plan with numbered phases and a JSON phases block
-   - **Run 3-way consultation** and add a `## Consultation` section
-   - **COMMIT** the plan file
-   - Run `porch done` → hits `plan_approval` gate
-   - Run `porch gate` → **STOP and wait for human**
-
-3-5. **Implement → Defend → Evaluate** (per plan phase): See detailed section below
-
-6. **Review** - Document lessons learned, run 3-way review, create PR
-   - Write the review document (`codev/reviews/XXXX-spec-name.md`)
-   - **Run 3-way parallel review focused on IMPLEMENTATION quality**:
-     ```bash
-     consult --model gemini --type pr-ready pr $PR_NUMBER &
-     consult --model codex --type pr-ready pr $PR_NUMBER &
-     consult --model claude --type pr-ready pr $PR_NUMBER &
-     wait
-     ```
-   - Address any REQUEST_CHANGES feedback before creating the PR
-   - Include the 3-way review summary in your PR description
-
-   **Note**: The Architect will run a separate 3-way review focused on **integration** concerns.
+Porch handles:
+- Spawning Claude to create artifacts (spec, plan, code)
+- Running 3-way consultations (Gemini, Codex, Claude)
+- Iterating based on feedback
+- Enforcing phase transitions
 
-### 🚨 CRITICAL: Implement → Defend → Evaluate Cycle 🚨
+### Gates: When to STOP
 
-**For EACH plan phase (phase_1, phase_2, etc.), you MUST complete the full I→D→E cycle WITH commits and porch calls.**
+Porch has two human approval gates:
 
-**This is NOT optional. Porch runs phase completion checks that verify your commit.**
-
-#### The Required Workflow (for each plan phase):
+| Gate | When | What to do |
+|------|------|------------|
+| `spec-approval` | After spec is written | **STOP** and wait |
+| `plan-approval` | After plan is written | **STOP** and wait |
 
+When porch outputs:
 ```
-┌─────────────────────────────────────────────────────────────┐
-│  PHASE N: [Title from plan]                                 │
-├─────────────────────────────────────────────────────────────┤
-│  1. IMPLEMENT                                               │
-│     - Write the code for this phase                         │
-│     - Run `porch done XXXX` → advances to defend           │
-│                                                             │
-│  2. DEFEND                                                  │
-│     - Write tests for the code                              │
-│     - Run `porch done XXXX` → advances to evaluate         │
-│                                                             │
-│  3. EVALUATE                                                │
-│     - Run 3-way consultation on implementation              │
-│     - Address any feedback                                  │
-│     - **COMMIT everything** (code + tests + consultation)   │
-│     - Run `porch done XXXX` → runs PHASE COMPLETION CHECKS │
-│                                                             │
-│  Phase completion checks verify your commit has:            │
-│     ✓ Build passes                                          │
-│     ✓ Tests pass                                            │
-│     ✓ Commit includes code files                            │
-│     ✓ Commit includes test files                            │
-│     ✓ Commit message mentions 3-way review                  │
-│                                                             │
-│  If checks fail → FIX and try `porch done` again           │
-│  If checks pass → Advances to next phase                    │
-└─────────────────────────────────────────────────────────────┘
+GATE: spec-approval
+Human approval required. STOP and wait.
 ```
 
-#### Example Commit Message (end of phase):
-
-```
-[Spec 0074][Phase 1] Remove backend activity code
+You must:
+1. Output a clear message: "Spec ready for approval. Waiting for human."
+2. **STOP working**
+3. Wait for the human to run `porch approve XXXX spec-approval`
+4. After approval, run `porch next` again
 
-- Removed ActivitySummary types and interfaces
-- Removed getGitCommits, getModifiedFiles, getGitHubPRs functions
-- Removed /api/activity-summary endpoint
-- Added tests for remaining endpoints
-
-3-way review: Gemini APPROVE, Codex APPROVE, Claude APPROVE
-```
+### What You DON'T Do in Strict Mode
 
-#### What Happens If You Skip This
+- **Don't manually follow SPIR steps** - Porch handles this
+- **Don't run consult directly** - Porch runs 3-way reviews
+- **Don't edit status.yaml phase/iteration** - Only porch modifies state
+- **Don't call porch approve** - Only humans approve gates
+- **Don't skip gates** - Always stop and wait for approval
 
-If you do NOT call `porch done` after each stage:
-- Porch doesn't know you finished
-- Phase completion checks never run
-- Your work is not validated
-- The Architect will reject your PR
+## Soft Mode
 
-**DO NOT just implement everything and skip porch calls.**
+Spawned with: `af spawn --soft -p XXXX` or `af spawn --task "..."`
 
-Each `porch done` is a checkpoint that:
-1. Validates your work meets criteria
-2. Records your progress
-3. Ensures quality gates are enforced
+In soft mode, you follow the protocol document yourself. The architect monitors your work and verifies you're adhering to the protocol correctly.
 
-### TICK Protocol Summary
+### Startup Sequence
 
-TICK is for smaller, well-defined tasks:
-- Understand → Implement → Verify → Done
-
-Follow the TICK protocol documentation for details.
+```bash
+# Read the spec and/or plan
+cat codev/specs/XXXX-*.md
+cat codev/plans/XXXX-*.md
 
-## Spec Compliance (CRITICAL)
+# Read the protocol
+cat codev/protocols/spir/protocol.md
 
-**The spec is the source of truth. Code that doesn't match the spec is wrong, even if it "works".**
+# Start implementing
+```
 
-### Pre-Implementation Sanity Check (PISC)
+### The SPIR Protocol (Specify → Plan → Implement → Review)
 
-**Before writing ANY code, run this checklist:**
+1. **Specify**: Read or create the spec at `codev/specs/XXXX-name.md`
+2. **Plan**: Read or create the plan at `codev/plans/XXXX-name.md`
+3. **Implement**: Write code following the plan phases
+4. **Review**: Write lessons learned and create PR
 
-1. ✅ "Have I read the spec in the last 30 minutes?"
-2. ✅ "If the spec has a 'Traps to Avoid' section, have I read it?"
-3. ✅ "Does my planned approach match the spec's Technical Implementation section?"
-4. ✅ "If the spec has code examples, am I following them?"
-5. ✅ "Does the existing code I'm building on actually match the spec?"
+### Consultations
 
-**If ANY answer is "no" or "I'm not sure" → STOP and re-read the spec before proceeding.**
+Run 3-way consultations at checkpoints:
+```bash
+# After writing spec
+consult --model gemini --type spec-review spec XXXX &
+consult --model codex --type spec-review spec XXXX &
+consult --model claude --type spec-review spec XXXX &
+wait
 
-### The Trust Hierarchy
+# After writing plan
+consult --model gemini --type plan-review plan XXXX &
+consult --model codex --type plan-review plan XXXX &
+consult --model claude --type plan-review plan XXXX &
+wait
 
+# After implementation
+consult --model gemini --type impl-review pr N &
+consult --model codex --type impl-review pr N &
+consult --model claude --type impl-review pr N &
+wait
 ```
-SPEC (source of truth)
-  ↓
-PLAN (implementation guide derived from spec)
-  ↓
-EXISTING CODE (NOT TRUSTED - must be validated against spec)
-```
-
-**Never trust existing code over the spec.** Previous implementations may have drifted. The spec is always authoritative.
-
-### Avoiding "Fixing Mode"
 
-A dangerous pattern: You start looking at symptoms in code, making incremental fixes, copying existing patterns - without going back to the source of truth (spec). This leads to:
-- Cargo-culting existing patterns that may be wrong
-- Building on broken foundations
-- Implementing something different from what the spec describes
-
-**When you catch yourself "fixing" code:**
-1. STOP
-2. Ask: "What does the spec say about this?"
-3. Re-read the spec's Traps to Avoid section
-4. Verify existing code matches the spec before building on it
+## Deliverables
 
-### Phrases That Should Trigger Spec Re-reading
+- Spec at `codev/specs/XXXX-name.md`
+- Plan at `codev/plans/XXXX-name.md`
+- Review at `codev/reviews/XXXX-name.md`
+- Implementation code with tests
+- PR ready for architect review
 
-If you think or receive any of these, immediately re-read the spec:
-- "Does this match the spec?"
-- "What does the spec say about X?"
-- "Check the spec's Traps to Avoid section"
-- "Are you sure?"
-- "You're cargo-culting existing patterns"
+## Communication
 
-## Status Lifecycle
+### With the Architect
 
+If you're blocked or need help:
+```bash
+af send architect "Question about the spec..."
 ```
-spawning → implementing → blocked → implementing → pr-ready → complete
-               ↑______________|
-```
-
-### Status Definitions
-
-| Status | Meaning |
-|--------|---------|
-| `spawning` | Worktree created, Builder starting up |
-| `implementing` | Actively working on the spec |
-| `blocked` | Stuck, needs Architect help |
-| `pr-ready` | Implementation complete, ready for review |
-| `complete` | Merged, worktree can be cleaned up |
 
 ### Checking Status
 
 ```bash
-af status
+porch status      # (strict mode) Your project status
+af status         # All builders
 ```
 
-You can check your own status and see other builders. The Architect also monitors status.
-
-## Working in a Worktree
+## Notifications
 
-### Understanding Your Environment
-- You are in an isolated git worktree at `.builders/XXXX/`
-- You have your own branch: `builder/XXXX-spec-name`
-- Changes here don't affect main until merged
-- You can commit freely without affecting other Builders
+**ALWAYS notify the architect** via `af send` at these key moments:
 
-### File Access
-- Full access to your worktree
-- Read-only conceptual access to main (for reference)
-- Your spec is at `codev/specs/XXXX-spec-name.md`
-- Your plan is at `codev/plans/XXXX-spec-name.md`
+| When | What to send |
+|------|-------------|
+| **Gate reached** | `af send architect "Project XXXX: <gate-name> ready for approval"` |
+| **PR ready** | `af send architect "PR #N ready for review"` |
+| **PR merged** | `af send architect "Project XXXX complete. PR merged. Ready for cleanup."` |
+| **Blocked/stuck** | `af send architect "Blocked on X — need guidance"` |
+| **Escalation needed** | `af send architect "Issue too complex — recommend escalating to SPIR/TICK"` |
 
-## When to Report Blocked
+The architect may be working on other tasks and won't know you need attention unless you send a message. **Don't assume they're watching** — always notify explicitly.
 
-Report `blocked` status when:
-- Spec is ambiguous and you need clarification
-- You discover a dependency on another spec
-- You encounter an unexpected technical blocker
-- You need architectural guidance
-- Tests are failing for reasons outside your scope
+## When You're Blocked
 
-**Do NOT stay blocked silently.** Communicate your blocker clearly:
+If you encounter issues you can't resolve:
 
-1. Output a clear message in your terminal describing the blocker and options
-2. Add a `<!-- REVIEW(@architect): question here -->` comment in relevant code if applicable
-3. The Architect monitors builder status via `af status` and will see you're blocked
+1. **Output a clear blocker message** describing the problem and options
+2. **Use `af send architect "..."` to notify the Architect**
+3. **Wait for guidance** before proceeding
 
-Example blocker message to output:
+Example:
 ```
-## BLOCKED: Spec 0003
+## BLOCKED: Spec 0077
 Can't find the auth helper mentioned in spec. Options:
 1. Create a new auth helper
 2. Use a third-party library
@@ -334,67 +172,12 @@ Can't find the auth helper mentioned in spec. Options:
 Waiting for Architect guidance.
 ```
 
-The Architect will provide guidance via `af send` or PR comments.
-
-## Deliverables
-
-When done, a Builder should have:
-
-1. **Implementation** - Code that fulfills the spec
-2. **Tests** - Appropriate test coverage
-3. **Documentation** - Updated relevant docs (if needed)
-4. **Clean commits** - Atomic, well-messaged commits per phase
-5. **Review document** - As specified in the SPIDER protocol (`codev/reviews/XXXX-spec-name.md`)
-6. **PR-ready branch** - Ready for Architect review
-
-## Communication with Architect
-
-### Receiving Instructions
-The Architect provides:
-- Spec file path
-- Plan file path
-- Protocol to follow (SPIDER/TICK)
-- Context and constraints
-
-### Reporting Completion
-When implementation is complete:
-1. Run all tests
-2. Self-review the code
-3. Ensure all protocol artifacts are present (especially the review document for SPIDER)
-4. Create a PR: `gh pr create --title "[Spec XXXX] Description" --body "..."`
-5. Update status to `pr-ready`
-6. Wait for Architect review and approval
-7. **Merge your own PR** once approved: `gh pr merge --merge --delete-branch`
-
-**Important**: The Builder is responsible for merging after Architect approval. This ensures the Builder sees the merge succeed and can handle any final cleanup.
-
-### Receiving PR Feedback
-
-The Architect reviews PRs and leaves feedback as GitHub PR comments. When notified to check feedback:
-
-```bash
-# View PR comments
-gh pr view <PR_NUMBER> --comments
-
-# Or view the full PR with comments in browser
-gh pr view <PR_NUMBER> --web
-```
-
-**Workflow:**
-1. Architect leaves review comments on PR
-2. You receive a short message: "Check PR comments and address feedback"
-3. Run `gh pr view <PR_NUMBER> --comments` to see feedback
-4. Address the issues (High priority first, then Medium, Low is optional)
-5. Push fixes to the same branch
-6. Reply to PR comment when done or if clarification needed
-
 ## Constraints
 
-- **Stay in scope** - Only implement what's in your spec
-- **Don't modify shared config** - Without Architect approval
-- **Merge your own PRs** - After Architect approves, you are responsible for merging
-- **Don't spawn other Builders** - Only Architects spawn Builders
+- **Stay in scope** - Only implement what's in the spec
+- **Merge your own PRs** - After architect approves
 - **Keep worktree clean** - No untracked files, no debug code
-- **Follow the protocol** - All phases, all artifacts
-- **NEVER edit status.yaml directly** - Only porch commands modify project state
-- **NEVER call porch approve unless explicitly told to by the human** - Gates require human instruction to approve
+- **(Strict mode)** Run porch, don't bypass it
+- **(Strict mode)** Stop at gates - Human approval is required
+- **(Strict mode)** NEVER edit status.yaml directly
+- **(Strict mode)** NEVER call porch approve

package/skeleton/roles/consultant.md

@@ -5,16 +5,16 @@ You are a consultant providing a second perspective to support decision-making.
 ## Responsibilities
 
 1. **Understand context** - Grasp the problem and constraints being presented
-2. **Offer insights** - Provide alternatives or considerations that may have been missed
-3. **Be constructive** - Help improve the solution, don't just critique
-4. **Be direct** - Give honest, clear feedback without excessive hedging
-5. **Collaborate** - Work toward the best outcome alongside the primary agent
+2. **Verify before flagging** - Check actual project files (package.json, configs) before claiming something is wrong or missing. Framework conventions change between major versions.
+3. **Offer insights** - Provide alternatives or considerations that may have been missed
+4. **Be constructive** - Help improve the solution, don't just critique
+5. **Be direct** - Give honest, clear feedback without excessive hedging
 
 ## You Are NOT
 
 - An adversary or gatekeeper
 - A rubber stamp that just agrees
-- A code generator (unless specifically asked for snippets)
+- A source of generic advice that ignores actual project context
 
 ## Relationship to Other Roles
 
@@ -24,4 +24,4 @@ You are a consultant providing a second perspective to support decision-making.
 | Builder | Implements in isolation |
 | Consultant | Provides perspective, supports decisions |
 
-You think alongside the other agents, helping them see blind spots.
+You think alongside the other agents, helping them see blind spots. You have filesystem access — use it to verify your claims against the actual codebase.

package/skeleton/templates/AGENTS.md

@@ -8,7 +8,7 @@ This project uses **Codev** for AI-assisted development.
 
 ## Available Protocols
 
-- **SPIDER**: Multi-phase development with consultation (`codev/protocols/spider/protocol.md`)
+- **SPIR**: Multi-phase development with consultation (`codev/protocols/spir/protocol.md`)
 - **TICK**: Fast autonomous implementation (`codev/protocols/tick/protocol.md`)
 - **EXPERIMENT**: Disciplined experimentation (`codev/protocols/experiment/protocol.md`)
 - **MAINTAIN**: Codebase maintenance (`codev/protocols/maintain/protocol.md`)
@@ -60,7 +60,7 @@ For complete reference, see `codev/resources/commands/`:
 
 ## Configuration
 
-Customize Agent Farm behavior in `codev/config.json`:
+Agent Farm is configured via `af-config.json` at the project root. Created during `codev init` or `codev adopt`. Override via CLI flags: `--architect-cmd`, `--builder-cmd`, `--shell-cmd`.
 
 ```json
 {

package/skeleton/templates/CLAUDE.md

@@ -6,7 +6,7 @@ This project uses **Codev** for AI-assisted development.
 
 ## Available Protocols
 
-- **SPIDER**: Multi-phase development with consultation (`codev/protocols/spider/protocol.md`)
+- **SPIR**: Multi-phase development with consultation (`codev/protocols/spir/protocol.md`)
 - **TICK**: Fast autonomous implementation (`codev/protocols/tick/protocol.md`)
 - **EXPERIMENT**: Disciplined experimentation (`codev/protocols/experiment/protocol.md`)
 - **MAINTAIN**: Codebase maintenance (`codev/protocols/maintain/protocol.md`)
@@ -58,7 +58,7 @@ For complete reference, see `codev/resources/commands/`:
 
 ## Configuration
 
-Customize Agent Farm behavior in `codev/config.json`:
+Agent Farm is configured via `af-config.json` at the project root. Created during `codev init` or `codev adopt`. Override via CLI flags: `--architect-cmd`, `--builder-cmd`, `--shell-cmd`.
 
 ```json
 {

package/skeleton/templates/cheatsheet.md

@@ -41,7 +41,7 @@ Just like structuring a human team—clear roles, defined processes, explicit ha
 
 | Component | Purpose |
 |-----------|---------|
-| Protocols | Define HOW work happens (SPIDER, TICK, etc.) |
+| Protocols | Define HOW work happens (SPIR, TICK, etc.) |
 | Roles | Define WHO does what (Architect, Builder, Consultant) |
 | Parallelism | Scale by running multiple builders simultaneously |
 
@@ -60,7 +60,7 @@ A **protocol** is a structured workflow that defines how work progresses from id
 
 | Protocol | Use For | Phases |
 |----------|---------|--------|
-| **SPIDER** | New features | Specify → Plan → Implement → Defend → Evaluate → Review |
+| **SPIR** | New features | Specify → Plan → Implement → Review |
 | **TICK** | Amendments to existing specs | Task Identification → Coding → Kickout |
 | **MAINTAIN** | Codebase hygiene | Dead code removal, documentation sync |
 | **EXPERIMENT** | Research & prototyping | Hypothesis → Experiment → Conclude |
@@ -110,13 +110,15 @@ Architect-Builder orchestration. Used by both **humans and agents**—agents use
 
 | Command | Description |
 |---------|-------------|
-| `af start` | Start dashboard (port 4200, 4300, etc.) |
-| `af stop` | Stop all processes |
+| `af dash start` | Start dashboard (port 4200, 4300, etc.) |
+| `af dash stop` | Stop all processes |
 | `af spawn -p <id>` | Spawn a builder for project |
 | `af status` | Check status of all builders |
 | `af send <target> <msg>` | Send message (builder↔architect) |
 | `af cleanup -p <id>` | Clean up a builder worktree |
+| `af shell` | Spawn a utility shell |
 | `af open <file>` | Open file in dashboard viewer |
+| `af tower start` | Start cross-project tower |
 
 ### consult
 
@@ -143,7 +145,7 @@ Multi-agent consultation. Used by both humans and agents—**mostly agents** dur
 
 ## Quick Reference
 
-### SPIDER Checklist
+### SPIR Checklist
 
 ```
 [ ] Specify - Write spec in codev/specs/XXXX-name.md

package/skeleton/templates/projectlist.md

@@ -142,6 +142,6 @@ To see high-priority work, search for `priority: high`.
 Before starting a project, verify its dependencies are at least `implemented`.
 
 ### Protocol Selection
-- **SPIDER**: Most projects (formal spec → plan → implement → review)
+- **SPIR**: Most projects (formal spec → plan → implement → review)
 - **TICK**: Small, well-defined tasks (< 300 lines) or amendments to existing specs
 - **EXPERIMENT**: Research/prototyping before committing to a project