cluesmith · waleedkadous · Jul 28, 2026 · Jul 28, 2026
diff --git a/codev/protocols/air/protocol.json b/codev/protocols/air/protocol.json
@@ -30,13 +30,11 @@
       "checks": {
         "build": {
           "command": "npm run build",
-          "cwd": "packages/codev",
           "on_fail": "retry",
           "max_retries": 2
         },
         "tests": {
           "command": "npm test -- --exclude='**/e2e/**'",
-          "cwd": "packages/codev",
           "description": "Unit tests only - e2e tests run in PR phase",
           "on_fail": "retry",
           "max_retries": 2
@@ -72,7 +70,6 @@
         },
         "e2e_tests": {
           "command": "npm run test:e2e 2>&1 || echo 'e2e tests skipped (not configured)'",
-          "cwd": "packages/codev",
           "description": "Full e2e test suite",
           "optional": true
         }

diff --git a/codev/protocols/air/protocol.md b/codev/protocols/air/protocol.md
@@ -34,7 +34,6 @@ AIR is a minimal protocol for implementing small features (< 300 LOC) where the
 
 - Bug fixes → use **BUGFIX**
 - Features needing spec discussion → use **SPIR** or **ASPIR**
-- Amendments to existing specs → use **TICK**
 - Architectural changes → use **SPIR**
 - Complex features with multiple phases → use **SPIR** or **ASPIR**
 

diff --git a/codev/protocols/aspir/builder-prompt.md b/codev/protocols/aspir/builder-prompt.md
@@ -68,11 +68,33 @@ By default, the PR is opened during/after the final implement phase, with all ph
 
 The architect MAY request a PR at any point — for spec review, mid-implementation feedback, slicing a large spec into shippable PRs, etc. When the architect explicitly asks for a PR earlier (or for additional PRs), follow that direction. The prohibition is specifically on the *builder* autonomously deciding to open per-phase PRs without architect request.
 
+### Multi-PR Mechanics (when the architect requests sequential PRs)
+
+Your worktree is persistent — it survives across PR merges. When the architect asks for sequential PRs (e.g., to slice a large spec into shippable pieces), use this loop:
+
+1. Cut a branch, open a PR, wait for merge
+2. After merge: `git fetch origin <integration-branch> && git checkout -b <next-branch> origin/<integration-branch>` — where `<integration-branch>` is the branch the architect targets PRs at (usually `main`; check the open PR's `baseRefName` if unsure)
+3. Continue to the next slice, open another PR
+
+**Important**: Do NOT run `git checkout <integration-branch>` — git worktrees cannot check out a branch that's checked out elsewhere. Always branch off `origin/<integration-branch>` via fetch.
+
+Record PRs: `porch done {{project_id}} --pr <N> --branch <name>`
+Record merges: `porch done {{project_id}} --merged <N>`
+
+## Verify Phase
+
+After the final PR merges, the project enters the **verify** phase. You stay alive through verify:
+1. Pull the integration branch into your worktree
+2. Run `porch done {{project_id}}` to signal verification is ready
+3. The architect approves `verify-approval` when satisfied
+
+If verification is not needed: `porch verify {{project_id}} --skip "reason"`
+
 ## Notifications
 Always use `afx send architect "..."` to notify the architect at key moments:
 - **Gate reached**: `afx send architect "Project {{project_id}}: <gate-name> ready for approval"`
 - **PR ready**: `afx send architect "PR #N ready for review (project {{project_id}})"`
-- **PR merged**: `afx send architect "Project {{project_id}} complete. PR merged. Ready for cleanup."`
+- **PR merged**: `afx send architect "Project {{project_id}} PR merged. Entering verify phase."`
 - **Blocked**: `afx send architect "Blocked on project {{project_id}}: [reason]"`
 
 ## Handling Flaky Tests

diff --git a/codev/protocols/aspir/protocol.json b/codev/protocols/aspir/protocol.json
@@ -23,7 +23,7 @@
         "models": ["gemini", "codex", "claude"],
         "parallel": true
       },
-      "max_iterations": 8,
+      "max_iterations": 3,
       "on_complete": {
         "commit": true,
         "push": true
@@ -44,7 +44,7 @@
         "models": ["gemini", "codex", "claude"],
         "parallel": true
       },
-      "max_iterations": 8,
+      "max_iterations": 3,
       "on_complete": {
         "commit": true,
         "push": true
@@ -70,7 +70,7 @@
         "models": ["gemini", "codex", "claude"],
         "parallel": true
       },
-      "max_iterations": 8,
+      "max_iterations": 3,
       "on_complete": {
         "commit": true,
         "push": true
@@ -107,7 +107,7 @@
         "models": ["gemini", "codex", "claude"],
         "parallel": true
       },
-      "max_iterations": 8,
+      "max_iterations": 3,
       "on_complete": {
         "commit": true,
         "push": true
@@ -160,7 +160,7 @@
   },
   "defaults": {
     "mode": "strict",
-    "max_iterations": 8,
+    "max_iterations": 3,
     "verify": {
       "models": ["gemini", "codex", "claude"],
       "parallel": true

diff --git a/codev/protocols/aspir/templates/plan.md b/codev/protocols/aspir/templates/plan.md
@@ -182,23 +182,3 @@ Phase 1 ──→ Phase 2 ──→ Phase 3
 ## Notes
 [Additional context, assumptions, or considerations]
 
----
-
-## Amendment History
-
-This section tracks all TICK amendments to this plan. TICKs modify both the spec and plan together as an atomic unit.
-
-<!-- When adding a TICK amendment, add a new entry below this line in chronological order -->
-
-<!--
-### TICK-001: [Amendment Title] (YYYY-MM-DD)
-
-**Changes**:
-- [Phase added]: [Description of new phase]
-- [Phase modified]: [What was updated]
-- [Implementation steps]: [New steps added]
-
-**Review**: See `reviews/####-name-tick-001.md`
-
----
--->
diff --git a/codev/protocols/aspir/templates/spec.md b/codev/protocols/aspir/templates/spec.md
@@ -152,31 +152,3 @@ Note: All consultation feedback has been incorporated directly into the relevant
 ## Notes
 [Any additional context or considerations not covered above]
 
----
-
-## Amendments
-
-This section tracks all TICK amendments to this specification. TICKs are lightweight changes that refine an existing spec rather than creating a new one.
-
-<!-- When adding a TICK amendment, add a new entry below this line in chronological order -->
-
-<!--
-### TICK-001: [Amendment Title] (YYYY-MM-DD)
-
-**Summary**: [One-line description of what changed]
-
-**Problem Addressed**:
-[Why this amendment was needed - what gap or issue in the original spec]
-
-**Spec Changes**:
-- [Section modified]: [What changed and why]
-- [New section added]: [Purpose]
-
-**Plan Changes**:
-- [Phase added/modified]: [Description]
-- [Implementation steps]: [What was updated]
-
-**Review**: See `reviews/####-name-tick-001.md`
-
----
--->
diff --git a/codev/protocols/bugfix/builder-prompt.md b/codev/protocols/bugfix/builder-prompt.md
@@ -44,7 +44,7 @@ Follow the BUGFIX protocol. Read and internalize the protocol before starting an
 
 If the fix is too complex (> 300 LOC or architectural changes), notify the Architect via:
 ```bash
-afx send architect "Issue #{{issue.number}} is more complex than expected. [Reason]. Recommend escalating to SPIR/TICK."
+afx send architect "Issue #{{issue.number}} is more complex than expected. [Reason]. Recommend escalating to SPIR."
 ```
 
 ## Notifications

diff --git a/codev/protocols/bugfix/protocol.json b/codev/protocols/bugfix/protocol.json
@@ -50,13 +50,11 @@
         },
         "build": {
           "command": "npm run build",
-          "cwd": "packages/codev",
           "on_fail": "retry",
           "max_retries": 2
         },
         "tests": {
           "command": "npm test",
-          "cwd": "packages/codev",
           "on_fail": "retry",
           "max_retries": 2
         }

diff --git a/codev/protocols/experiment/protocol.md b/codev/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 SPIR), simple one-off scripts, well-understood implementations (use TICK)
+**Skip for**: Production code (use SPIR), simple one-off scripts
 
 ## Structure
 
@@ -129,11 +129,6 @@ Experiment 5 validated that [approach] achieves [results].
 See: experiments/5_validation_test/notes.md
 ```
 
-### Experiment → TICK
-For small, validated changes discovered during experimentation:
-- Use TICK for quick implementation
-- Reference experiment as justification
-
 ## Numbering Convention
 
 Use four-digit sequential numbering (consistent with project list):

diff --git a/codev/protocols/protocol-schema.json b/codev/protocols/protocol-schema.json
@@ -8,7 +8,7 @@
   "properties": {
     "name": {
       "type": "string",
-      "description": "Protocol identifier (e.g., 'spir', 'tick', 'bugfix')"
+      "description": "Protocol identifier (e.g., 'spir', 'bugfix', 'air')"
     },
     "version": {
       "type": "string",

diff --git a/codev/protocols/spike/protocol.md b/codev/protocols/spike/protocol.md
@@ -10,7 +10,7 @@ Time-boxed technical feasibility exploration. Answer "Can we do X?" and "What wo
 
 **Use for**: Quick technical feasibility investigations, proof-of-concept explorations, "can we do X?" questions, evaluating approaches before committing to SPIR
 
-**Skip for**: Production code (use SPIR), formal hypothesis testing (use EXPERIMENT), bug fixes (use BUGFIX), well-understood implementations (use TICK)
+**Skip for**: Production code (use SPIR), formal hypothesis testing (use EXPERIMENT), bug fixes (use BUGFIX)
 
 ### Spike vs Experiment
 

diff --git a/codev/protocols/spir/builder-prompt.md b/codev/protocols/spir/builder-prompt.md
@@ -68,11 +68,34 @@ By default, the PR is opened during/after the final implement phase, with all ph
 
 The architect MAY request a PR at any point — for spec review, mid-implementation feedback, slicing a large spec into shippable PRs, etc. When the architect explicitly asks for a PR earlier (or for additional PRs), follow that direction. The prohibition is specifically on the *builder* autonomously deciding to open per-phase PRs without architect request.
 
+### Multi-PR Mechanics (when the architect requests sequential PRs)
+
+Your worktree is persistent — it survives across PR merges. When the architect asks for sequential PRs (e.g., to slice a large spec into shippable pieces), use this loop:
+
+1. Cut a branch, open a PR, wait for merge
+2. After merge: `git fetch origin <integration-branch> && git checkout -b <next-branch> origin/<integration-branch>` — where `<integration-branch>` is the branch the architect targets PRs at (usually `main`; check the open PR's `baseRefName` if unsure)
+3. Continue to the next slice, open another PR
+4. Repeat
+
+**Important**: Do NOT run `git checkout <integration-branch>` — git worktrees cannot check out a branch that's checked out elsewhere. Always branch off `origin/<integration-branch>` via fetch.
+
+Record PRs in status.yaml: `porch done {{project_id}} --pr <N> --branch <name>`
+Record merges: `porch done {{project_id}} --merged <N>`
+
+## Verify Phase
+
+After the final PR merges, the project enters the **verify** phase. You stay alive through verify:
+1. Pull the integration branch into your worktree
+2. Run `porch done {{project_id}}` to signal verification is ready
+3. The architect approves `verify-approval` when satisfied
+
+If verification is not needed: `porch verify {{project_id}} --skip "reason"`
+
 ## Notifications
 Always use `afx send architect "..."` to notify the architect at key moments:
 - **Gate reached**: `afx send architect "Project {{project_id}}: <gate-name> ready for approval"`
 - **PR ready**: `afx send architect "PR #N ready for review (project {{project_id}})"`
-- **PR merged**: `afx send architect "Project {{project_id}} complete. PR merged. Ready for cleanup."`
+- **PR merged**: `afx send architect "Project {{project_id}} PR merged. Entering verify phase."`
 - **Blocked**: `afx send architect "Blocked on project {{project_id}}: [reason]"`
 
 ## Handling Flaky Tests

diff --git a/codev/protocols/spir/protocol.json b/codev/protocols/spir/protocol.json
@@ -24,7 +24,7 @@
         "models": ["gemini", "codex", "claude"],
         "parallel": true
       },
-      "max_iterations": 8,
+      "max_iterations": 3,
       "on_complete": {
         "commit": true,
         "push": true
@@ -46,7 +46,7 @@
         "models": ["gemini", "codex", "claude"],
         "parallel": true
       },
-      "max_iterations": 8,
+      "max_iterations": 3,
       "on_complete": {
         "commit": true,
         "push": true
@@ -73,7 +73,7 @@
         "models": ["gemini", "codex", "claude"],
         "parallel": true
       },
-      "max_iterations": 8,
+      "max_iterations": 3,
       "on_complete": {
         "commit": true,
         "push": true
@@ -110,7 +110,7 @@
         "models": ["gemini", "codex", "claude"],
         "parallel": true
       },
-      "max_iterations": 8,
+      "max_iterations": 3,
       "on_complete": {
         "commit": true,
         "push": true
@@ -163,7 +163,7 @@
   },
   "defaults": {
     "mode": "strict",
-    "max_iterations": 8,
+    "max_iterations": 3,
     "verify": {
       "models": ["gemini", "codex", "claude"],
       "parallel": true