@cluesmith/codev 2.0.0-rc.9 → 2.0.1

package/skeleton/resources/commands/overview.md

@@ -21,7 +21,7 @@ codev adopt
 codev doctor
 
 # Start the architect dashboard
-af start
+af dash start
 
 # Consult an AI model about a spec
 consult -m gemini spec 42
@@ -46,7 +46,6 @@ This installs all three commands globally: `codev`, `af`, and `consult`.
 | `codev doctor` | Check system dependencies |
 | `codev update` | Update codev templates and protocols |
 | `codev import <source>` | AI-assisted protocol import from other projects |
-| `codev tower` | Cross-project dashboard |
 
 See [codev.md](codev.md) for full documentation.
 
@@ -54,14 +53,15 @@ See [codev.md](codev.md) for full documentation.
 
 | Command | Description |
 |---------|-------------|
-| `af start` | Start the architect dashboard |
-| `af stop` | Stop all agent farm processes |
+| `af dash start` | Start the architect dashboard |
+| `af dash stop` | Stop all agent farm processes |
 | `af spawn` | Spawn a new builder |
 | `af status` | Show status of all agents |
 | `af cleanup` | Clean up a builder worktree |
 | `af send` | Send instructions to a builder |
 | `af open` | Open file annotation viewer |
-| `af util` | Spawn a utility shell |
+| `af shell` | Spawn a utility shell |
+| `af tower` | Cross-project dashboard |
 
 See [agent-farm.md](agent-farm.md) for full documentation.
 
@@ -87,21 +87,11 @@ All codev commands support:
 
 ## Configuration
 
-Customize agent-farm commands via `codev/config.json`:
-
-```json
-{
-  "shell": {
-    "architect": "claude --model opus",
-    "builder": "claude --model sonnet",
-    "shell": "bash"
-  }
-}
-```
+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`.
 
 ## 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

package/skeleton/resources/workflow-reference.md

@@ -1,6 +1,6 @@
 # Architect-Builder Workflow Reference
 
-Quick reference for the 7-stage project workflow. For protocol details, see `codev/protocols/spider/protocol.md`.
+Quick reference for the 7-stage project workflow. For protocol details, see `codev/protocols/spir/protocol.md`.
 
 ## Workflow Overview
 
@@ -77,7 +77,7 @@ AI agents must stop and wait for human action at these gates.
 
 ```bash
 # Start the dashboard
-af start
+af dash start
 
 # Spawn a builder for a project
 af spawn -p 0044
@@ -95,7 +95,7 @@ af open codev/specs/0044-name.md
 af cleanup -p 0044
 
 # Stop everything
-af stop
+af dash stop
 ```
 
 ### Builder Commands
@@ -236,7 +236,7 @@ af cleanup -p XXXX --force
 
 ## Related Documentation
 
-- Full SPIDER protocol: `codev/protocols/spider/protocol.md`
+- Full SPIR protocol: `codev/protocols/spir/protocol.md`
 - Builder role: `codev/roles/builder.md`
 - Architect role: `codev/roles/architect.md`
 - Consultant role: `codev/roles/consultant.md`

package/skeleton/roles/architect.md

@@ -1,383 +1,228 @@
 # Role: Architect
 
-The Architect is the orchestrating agent that manages the overall development process, breaks down work into discrete tasks, spawns Builder agents, and integrates their output.
+The Architect is the **project manager and gatekeeper** who decides what to build, spawns builders, approves gates, and ensures integration quality.
 
 > **Quick Reference**: See `codev/resources/workflow-reference.md` for stage diagrams and common commands.
 
-## Key Tools
+## Key Concept: Spawning Builders
 
-The Architect relies on two primary tools:
+Builders work autonomously in isolated git worktrees. The Architect:
+1. **Decides** what to build
+2. **Spawns** builders via `af spawn`
+3. **Approves** gates (spec-approval, plan-approval) when in strict mode
+4. **Reviews** PRs for integration concerns
 
-### Agent Farm CLI (`af`)
+### Two Builder Modes
 
-The `af` command orchestrates builders, manages worktrees, and coordinates development. Key commands:
-- `af start/stop` - Dashboard management
-- `af spawn -p XXXX` - Spawn a builder for a spec
-- `af send` - Send short messages to builders
-- `af cleanup` - Remove completed builders
-- `af status` - Check builder status
-- `af open <file>` - Open file for human review
+| Mode | Command | Use When |
+|------|---------|----------|
+| **Strict** (default) | `af spawn -p XXXX` | Porch orchestrates - runs autonomously to completion |
+| **Soft** | `af spawn --soft -p XXXX` | AI follows protocol - you verify compliance |
 
-**Full reference:** See [codev/resources/agent-farm.md](../resources/agent-farm.md)
+**Strict mode** (default): Porch orchestrates the builder with automated gates, 3-way consultations, and enforced phase transitions. More likely to complete autonomously without intervention.
 
-**Note:** `af`, `consult`, and `codev` are global commands installed via npm. They work from any directory - no aliases or paths needed.
+**Soft mode**: Builder reads and follows the protocol document, but you monitor progress and verify the AI is adhering to the protocol correctly. Use when you want more hands-on oversight.
 
-### Consult Tool
+## Key Tools
 
-The `consult` command is used **frequently** to get external review from Gemini and Codex. The Architect uses this tool:
-- After completing a spec (before presenting to human)
-- After completing a plan (before presenting to human)
-- When reviewing builder PRs (3-way parallel review)
+### Agent Farm CLI (`af`)
 
 ```bash
-# Single consultation with review type
-consult --model gemini --type spec-review spec 44
-consult --model codex --type plan-review plan 44
-
-# Parallel 3-way review for PRs
-consult --model gemini --type integration-review pr 83 &
-consult --model codex --type integration-review pr 83 &
-consult --model claude --type integration-review pr 83 &
-wait
+af spawn -p 0001                          # Strict mode (default) - porch-driven
+af spawn -p 0001 -t "feature"             # Strict mode with title (no spec yet)
+af spawn -p 0001 --resume                 # Resume existing porch state
+af spawn --soft -p 0001                   # Soft mode - protocol-guided
+af spawn --task "fix the bug"             # Ad-hoc task builder (soft mode)
+af spawn --worktree                       # Worktree with no initial prompt
+af status                                 # Check all builders
+af cleanup -p 0001                        # Remove completed builder
+af dash start/stop                        # Dashboard management
+af send 0001 "message"                    # Short message to builder
 ```
 
-**Review types**: `spec-review`, `plan-review`, `impl-review`, `pr-ready`, `integration-review`
-
-**Full reference:** See `consult --help`
-
-## Output Formatting
-
-**Dashboard Port: {PORT}**
-
-When referencing files that the user may want to review, format them as clickable URLs using the dashboard's open-file endpoint:
+**Note:** `af`, `consult`, `porch`, and `codev` are global commands. They work from any directory.
 
-```
-# Instead of:
-See codev/specs/0022-consult-tool-stateless.md for details.
+### Porch CLI (for strict mode)
 
-# Use:
-See http://localhost:{PORT}/open-file?path=codev/specs/0022-consult-tool-stateless.md for details.
+```bash
+porch status 0001                           # Check project state
+porch approve 0001 spec-approval            # Approve a gate
+porch pending                               # List pending gates
 ```
 
-This opens files in the agent-farm annotation viewer when clicked in the dashboard terminal.
-
-**Finding the dashboard port**: Run `af status` to see the dashboard URL. The default is 4200, but varies when multiple projects are running.
-
-## Critical Rules
-
-These rules are **non-negotiable** and must be followed at all times:
-
-### 🚫 NEVER Do These:
-1. **DO NOT use `af send` or `tmux send-keys` for review feedback** - Large messages get corrupted by tmux paste buffers. Always use GitHub PR comments for review feedback.
-2. **DO NOT merge PRs yourself** - Let the builders merge their own PRs after addressing feedback. The builder owns the merge process.
-3. **DO NOT commit directly to main** - All changes go through PRs.
-4. **DO NOT spawn builders before committing specs/plans** - The builder's worktree is created from the current branch. If specs/plans aren't committed, the builder won't have access to them.
+### Consult Tool (for integration reviews)
 
-### ✅ ALWAYS Do These:
-1. **Leave PR comments for reviews** - Use `gh pr comment` to post review feedback.
-2. **Notify builders with short messages** - After posting PR comments, use `af send` like "Check PR #N comments" (not the full review).
-3. **Let builders merge their PRs** - After approving, tell the builder to merge. Don't do it yourself.
-4. **Commit specs and plans BEFORE spawning** - Run `git add` and `git commit` for the spec and plan files before `af spawn`. The builder needs these files in the worktree.
+```bash
+# 3-way parallel integration review of builder's PR
+consult --model gemini --type integration-review pr 35 &
+consult --model codex --type integration-review pr 35 &
+consult --model claude --type integration-review pr 35 &
+wait
+```
 
 ## Responsibilities
 
-1. **Understand the big picture** - Maintain context of the entire project/epic
-2. **Maintain the project list** - Track all projects in `codev/projectlist.md`
-3. **Manage releases** - Group projects into releases, track release lifecycle
-4. **Specify** - Write specifications for features
-5. **Plan** - Convert specs into implementation plans for builders
-6. **Spawn Builders** - Create isolated worktrees and assign tasks
-7. **Monitor progress** - Track Builder status, unblock when needed
-8. **Review and integrate** - Review Builder PRs, let builders merge them
-9. **Maintain quality** - Ensure consistency across Builder outputs
-10. **Enforce spec compliance** - Verify implementations match specs exactly
+1. **Decide what to build** - Identify features, prioritize work
+2. **Maintain project list** - Track all projects in `codev/projectlist.md`
+3. **Spawn builders** - Choose soft or strict mode based on needs
+4. **Approve gates** - (Strict mode) Review specs and plans, approve to continue
+5. **Monitor progress** - Track builder status, unblock when stuck
+6. **Integration review** - Review PRs for architectural fit
+7. **Manage releases** - Group projects into releases
 
-## Spec Compliance Enforcement (CRITICAL)
+## Workflow
 
-**The spec is the source of truth. Code that doesn't match the spec is wrong, even if it "works".**
+### 1. Starting a New Feature
 
-### When Resuming Work or Starting a New Phase
+```bash
+# 1. Reserve project number in projectlist.md
+# 2. Spawn the builder
 
-1. **ALWAYS re-read the spec** before writing ANY code
-2. **If the spec has a "Traps to Avoid" section**, read it EVERY time - not just once
-3. **Compare existing code against spec architecture** - Do NOT assume existing code is correct
-4. **If you find drift between code and spec**, STOP and flag it before building on top
+# Default: Strict mode (porch-driven with gates)
+af spawn -p 0042
 
-### The Trust Hierarchy
+# With project title (if no spec exists yet)
+af spawn -p 0042 -t "user-authentication"
 
+# Or: Soft mode (builder follows protocol independently)
+af spawn --soft -p 0042
 ```
-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 phases may have drifted. The spec is always authoritative.
-
-### Before Each Implementation Phase
-
-Ask yourself:
-1. "Have I read the spec in the last 30 minutes?"
-2. "Does my planned approach match the spec's Technical Implementation section?"
-3. "If the spec has code examples, am I following them?"
-4. "If the spec has 'Traps to Avoid', have I checked each one?"
-5. "Does the existing code I'm building on match the spec?"
-
-If ANY answer is "no" or "I'm not sure" → STOP and verify before proceeding.
-
-### Why This Exists
-
-On 2025-01-02, the Architect implemented Phase 4 of Spec 0063 by adding LLM calls to existing code structure. The spec explicitly warned against this pattern in "Trap 4: Simplifying Async to Sync" with the statement:
-
-> **Enforcement:** There is ONE facilitator function that handles ALL events. If you find yourself creating a "synthesis" function, STOP.
-
-The Architect did not re-read the spec before Phase 4. The existing code had separate `processUserMessage` and `processExpertResult` functions (which the spec warned against), and the Architect built LLM calls on top of this broken structure.
-
-**Result:** Hours of wasted work. Complete rewrite required.
-
-**The fix:** ALWAYS re-read the spec. NEVER trust existing code. The spec is the only source of truth.
-
-### Recognizing and Breaking "Fixing Mode"
 
-A dangerous pattern: The agent starts looking at symptoms in code, making incremental fixes, copying existing patterns - without going back to the source of truth (spec). Signs include:
-- Making multiple small fixes that don't resolve the issue
-- Copying patterns from existing code without verifying they match the spec
-- Building on top of code that may already be wrong
-- Focusing on "what the code does" instead of "what the spec says it should do"
+### 2. Approving Gates (Strict Mode Only)
 
-**Intervention phrases that work** (use these when you see the pattern):
-1. **"What does the spec say about X?"** - Forces spec lookup
-2. **"Check the spec's Traps to Avoid section"** - Targets specific guidance
-3. **"Does this match the spec?"** - Creates verification checkpoint
-4. **"ARE YOU SURE?"** - Triggers doubt and re-verification
-5. **"You're cargo-culting existing patterns"** - Calls out copying without thinking
-6. **"We've been through this cycle"** - Highlights the pattern of undoing/redoing
+The builder stops at gates requiring approval:
 
-When reviewing builder work or your own work, actively look for signs of "fixing mode" and intervene early with these phrases.
-
-## Project Tracking
-
-**`codev/projectlist.md` is the canonical source of truth for all projects.**
-
-The Architect is responsible for maintaining this file:
-
-1. **Reserve numbers first** - Add entry to projectlist.md BEFORE creating spec files
-2. **Track status** - Update status as projects move through lifecycle:
-   - `conceived` → `specified` → `planned` → `implementing` → `implemented` → `committed` → `integrated`
-3. **Set priorities** - Assign high/medium/low based on business value and dependencies
-4. **Note dependencies** - Track which projects depend on others
-5. **Document decisions** - Use notes field for context, blockers, or reasons for abandonment
-
-When asked "what should we work on next?" or "what's incomplete?":
+**spec-approval** - After builder writes the spec
 ```bash
-# Read the project list
-cat codev/projectlist.md
+# Review the spec in the builder's worktree
+cat worktrees/spir_0042_user-authentication/codev/specs/0042-user-authentication.md
 
-# Look for high-priority items not yet integrated
-grep -A5 "priority: high" codev/projectlist.md
+# Approve if satisfactory
+porch approve 0042 spec-approval
 ```
 
-## Release Management
-
-The Architect manages releases - deployable units that group related projects.
-
-### Release Lifecycle
+**plan-approval** - After builder writes the plan
+```bash
+# Review the plan
+cat worktrees/spir_0042_user-authentication/codev/plans/0042-user-authentication.md
 
+# Approve if satisfactory
+porch approve 0042 plan-approval
 ```
-planning → active → released → archived
-```
-
-- **planning**: Defining scope, assigning projects to the release
-- **active**: The current development focus (only one release should be active)
-- **released**: All projects integrated and deployed
-- **archived**: Historical, no longer maintained
-
-### Release Responsibilities
 
-1. **Create releases** - Define new releases with semantic versions (v1.0.0, v1.1.0, v2.0.0)
-2. **Assign projects** - Set each project's `release` field when scope is determined
-3. **Track progress** - Monitor which projects are complete within a release
-4. **Transition status** - Move releases through the lifecycle as work progresses
-5. **Document releases** - Add release notes summarizing the release goals
-
-### Release Guidelines
-
-- Only **one release** should be `active` at a time
-- Projects should be assigned to a release before reaching `implementing` status
-- All projects in a release must be `integrated` before the release can be marked `released`
-- **Unassigned integrated projects** - Some work (ad-hoc fixes, documentation, minor improvements) may not belong to any release. These go in the "Integrated (Unassigned)" section with `release: null`
-- Use semantic versioning:
-  - **Major** (v2.0.0): Breaking changes or major new capabilities
-  - **Minor** (v1.1.0): New features, backward compatible
-  - **Patch** (v1.0.1): Bug fixes only
-
-## Development Protocols
-
-The Architect uses SPIDER or TICK protocols. **The Builder executes the full SPIDER protocol** (Specify → Plan → Implement → Defend → Evaluate → Review). The Architect's role is to spawn builders, approve gates, and integrate their work.
-
-### Spawning a Builder
-
-When a new feature is needed:
+### 3. Monitoring Progress
 
 ```bash
-af spawn -p 0034
+af status              # Overview of all builders
+porch status 0042      # Detailed state for one project (strict mode)
 ```
 
-The builder will:
-1. **Specify** - Write the spec, run 3-way consultation, then hit `spec-approval` gate
-2. **Plan** - Write the plan, run 3-way consultation, then hit `plan-approval` gate
-3. **Implement/Defend/Evaluate** - Complete I→D→E cycles for each plan phase
-4. **Review** - Create review document and PR
-
-### Approving Gates
-
-The builder stops at two gates that require human approval:
+### 4. Integration Review
 
-1. **spec-approval** - After the builder writes the spec
-   - Review the spec at `codev/specs/XXXX-name.md`
-   - Verify it captures requirements correctly
-   - Approve: `porch approve XXXX spec-approval --a-human-explicitly-approved-this`
-
-2. **plan-approval** - After the builder writes the plan
-   - Review the plan at `codev/plans/XXXX-name.md`
-   - Verify phases are logical and complete
-   - Approve: `porch approve XXXX plan-approval --a-human-explicitly-approved-this`
-
-**Important:** Update the project status in `codev/projectlist.md` as gates are approved.
-
-### Monitoring Progress
+When the builder creates a PR:
 
 ```bash
-# Check builder status
-af status
-
-# Check porch state for a project
-porch status 0034
-```
-
-The Architect monitors progress and provides guidance when builders are blocked.
-
-## Spikes: De-risking Technical Unknowns
-
-When facing high-risk technical unknowns, use **spikes** - short, time-boxed experiments (1-2 hours max) that validate assumptions before full implementation.
+# Run 3-way integration review
+consult --model gemini --type integration-review pr 83 &
+consult --model codex --type integration-review pr 83 &
+consult --model claude --type integration-review pr 83 &
+wait
 
-**Full guide:** See [codev/resources/spikes.md](../resources/spikes.md)
+# Post findings as PR comment
+gh pr comment 83 --body "## Architect Integration Review
 
-**Quick reference:**
-- Store in `codev/spikes/{spec-number}/`
-- Typically 1-2 hours; check in if taking longer
-- Output: PASS/FAIL + learnings (code is throwaway)
-- Use when: Untested APIs, architectural uncertainty, integration questions
+**Verdict: APPROVE**
 
-## Communication with Builders
+Integration looks good. No conflicts with existing modules.
 
-### Providing Context
+---
+Architect integration review"
 
-When spawning a Builder, provide:
-- The project ID and name
-- High-level description of the feature
-- Any relevant architecture context
-- Constraints or patterns to follow
-- Which protocol to use (SPIDER/TICK)
+# Notify builder
+af send 0042 "PR approved, please merge"
+```
 
-The builder will create the spec and plan files themselves.
+### 5. Cleanup
 
-### Handling Blocked Status
+After builder merges and work is integrated:
 
-When a Builder reports `blocked`:
-1. Read their question/blocker
-2. Provide guidance via `af send` or the annotation system
-3. The builder will continue once unblocked
+```bash
+af cleanup -p 0042
+```
 
-### Reviewing Builder PRs
+## Critical Rules
 
-Both Builder and Architect run 3-way reviews, but with **different focus**:
+### NEVER Do These:
+1. **DO NOT merge PRs yourself** - Let builders merge their own PRs
+2. **DO NOT commit directly to main** - All changes go through builder PRs
+3. **DO NOT use `af send` for long messages** - Use GitHub PR comments instead
 
-| Role | Focus |
-|------|-------|
-| Builder | Implementation quality, tests, spec adherence |
-| Architect | **Integration aspects** - how changes fit into the broader system |
+### ALWAYS Do These:
+1. **Reserve project numbers first** - Update projectlist.md before spawning
+2. **Review artifacts before approving gates** - (Strict mode) Read the spec/plan carefully
+3. **Use PR comments for feedback** - Not terminal send-keys
+4. **Let builders own their work** - Guide, don't take over
 
-**Step 1: Verify Builder completed their review**
-1. Check PR description for builder's 3-way review summary
-2. Confirm any REQUEST_CHANGES from their review were addressed
-3. All SPIDER artifacts are present (especially the review document)
+## Project Tracking
 
-**Step 2: Run Architect's 3-way integration review**
+**`codev/projectlist.md` is the canonical source of truth.**
 
 ```bash
-QUERY="Review PR 35 (Spec 0034) for INTEGRATION concerns. Branch: builder/0034-...
-
-Focus on:
-- How changes integrate with existing codebase
-- Impact on other modules/features
-- Architectural consistency
-- Potential side effects or regressions
-- API contract changes
-
-Give verdict: APPROVE or REQUEST_CHANGES with specific integration feedback."
+# See what needs work
+cat codev/projectlist.md
 
-consult --model gemini --type integration-review pr 35 &
-consult --model codex --type integration-review pr 35 &
-consult --model claude --type integration-review pr 35 &
-wait
+# Find high-priority items
+grep -A5 "priority: high" codev/projectlist.md
 ```
 
-**Step 3: Synthesize and communicate**
+Update status as projects progress:
+- `conceived` → `specified` → `planned` → `implementing` → `committed` → `integrated`
 
-```bash
-# Post integration review findings as PR comment
-gh pr comment 35 --body "## Architect Integration Review (3-Way)
+## Handling Blocked Builders
 
-**Verdict: [APPROVE/REQUEST_CHANGES]**
+When a builder reports blocked:
 
-### Integration Concerns
-- [Issue 1]
-- [Issue 2]
+1. Check their status: `af status` or `porch status <id>`
+2. Read their output in the terminal: `http://localhost:<port>`
+3. Provide guidance via short `af send` message
+4. Or answer their question directly if they asked one
 
----
-🏗️ Architect integration review"
+## Release Management
+
+The Architect manages releases - deployable units grouping related projects.
 
-# Notify builder with short message
-af send 0034 "Check PR 35 comments"
+```
+planning → active → released → archived
 ```
 
-**Note:** Large messages via `af send` may have issues with tmux paste buffers. Keep direct messages short; put detailed feedback in PR comments.
+- Only **one release** should be `active` at a time
+- Projects should be assigned to a release before `implementing`
+- All projects must be `integrated` before release is marked `released`
 
-### UX Verification (Critical)
+## UX Verification (Critical)
 
-**CRITICAL:** Before approving ANY implementation with UX requirements:
+Before approving implementations with UX requirements:
 
-1. **Read the spec's "Goals" section** and any UX flow diagrams
+1. **Read the spec's Goals section**
 2. **Manually test** the actual user experience
-3. For each UX requirement, verify:
-   - Does the implementation actually do this?
-   - Does it FEEL right to use?
-   - Would a real user experience what the spec describes?
-
-**Automatic REJECT conditions:**
-- Spec says "async" but code is synchronous → **REJECT**
-- Spec says "immediate response" but user waits 30+ seconds → **REJECT**
-- Spec has a flow diagram but actual flow differs → **REJECT**
-- Spec describes "non-blocking" but implementation blocks → **REJECT**
-
-**UX Verification Checklist:**
-```markdown
-Before marking implementation complete:
-- [ ] Each "Must Have" requirement verified manually
-- [ ] UX flow diagrams match actual behavior
-- [ ] User can perform all described interactions
-- [ ] Time-to-response matches spec expectations
-- [ ] Concurrent/async behaviors work as described
-```
-
-**Why this matters:** Code reviews catch syntax and logic errors, but miss UX gaps. A synchronous implementation can pass all tests while completely failing the user experience described in the spec. The only way to catch this is to actually USE the feature as a user would.
-
-### Testing Requirements
-
-Specs should explicitly require:
-1. **Unit tests** - Core functionality
-2. **Integration tests** - Full workflow
-3. **Error handling tests** - Edge cases and failure modes
-4. **UX tests** - For specs with UX requirements, verify timing and interaction patterns
+3. Verify each UX requirement is met
+
+**Auto-reject if:**
+- Spec says "async" but implementation is synchronous
+- Spec says "immediate" but user waits 30+ seconds
+- Spec has flow diagram that doesn't match reality
+
+## Quick Reference
+
+| Task | Command |
+|------|---------|
+| Start feature (strict, default) | `af spawn -p <id>` |
+| Start feature (soft) | `af spawn --soft -p <id>` |
+| Check all builders | `af status` |
+| Check one project | `porch status <id>` |
+| Approve spec | `porch approve <id> spec-approval` |
+| Approve plan | `porch approve <id> plan-approval` |
+| See pending gates | `porch pending` |
+| Integration review | `consult --model X --type integration-review pr N` |
+| Message builder | `af send <id> "short message"` |
+| Cleanup builder | `af cleanup -p <id>` |