Weave Plan

Weave Plan

Get implementation plans from independent adversarial workers in parallel, then synthesize the best plan. Host-native sub-agents are the default; separate model CLIs are optional. This is a project-read-only command — no files in your repository are written, edited, or deleted. Session artifacts (worker outputs, prompts, synthesis results) are persisted to $AI_AIP_ROOT for post-session inspection; this directory is outside your repository. The output is a finalized Claude Code plan ready for execution.

The task description comes from $ARGUMENTS. If no arguments are provided, ask the user what they want planned.

Worker selection

Before any other unresolved configuration choice or operational step, read references/worker-backends.md. Resolve worker_backend from --workers=subagents|model-clis using that reference; if the flag is absent, ask its worker question first. If interactive choice is unavailable, honor its documented headless default.

The selected backend governs the whole session: dispatch, retry, judging, refinement, artifacts, session metadata, and presentation. The shared reference adapts provider-named examples across every later phase to that backend.

When worker_backend == subagents, use only the reference's native sub-agent path. Skip every model-CLI detection, timeout question, timeout resolution, retry, fallback, and dispatch instruction below. Every such instruction below is conditional on worker_backend == model-clis.

Phase 0: Enter Plan Mode

Call EnterPlanMode immediately. The final output of this command is a Claude plan file — the main agent stays in plan mode throughout and does NOT exit plan mode.

The main agent in plan mode can use readonly tools (Read, Grep, Glob) and launch sub-agents. All non-readonly operations (Bash, Write to non-plan files, Edit) are delegated to sub-agents spawned with mode: "default".

If plan mode is unavailable (e.g., headless claude -p invocation), proceed normally — the phase structure still produces a plan, and the final synthesis is presented as markdown text instead of written to a plan file.

Do NOT call ExitPlanMode — the user reviews the plan file and approves execution via the UI.

Emit to chat: Plan mode active — drafting implementation plan…

Phase 1: Gather Context

Goal: Understand the project state and the planning request.

1. Read CLAUDE.md / AGENTS.md if present — the main agent does this directly (Read is available in plan mode). Project conventions constrain valid plans.

2. Capture the task: Use $ARGUMENTS as the task description. If $ARGUMENTS is empty, ask the user what they want planned.

3. Launch a context-gather Task agent to collect git state via Bash commands.

   Launch a Task agent (subagent_type: "general-purpose", mode: "default") with this prompt:

   Gather git context for the current repository. Run the following commands and return the results verbatim:

   1. Determine the trunk branch:

      git remote show origin | grep 'HEAD branch'
      

      Fall back to main, then master, if detection fails.

   2. Diff stats against trunk:

      git diff origin/<trunk>...HEAD --stat
      

   3. Commit log since trunk:

      git log origin/<trunk>..HEAD --oneline
      

   4. Current branch and short SHA:

      git branch --show-current
      

      git rev-parse --short HEAD
      

   Return the trunk branch name, diff stats, commit log, current branch, and short SHA as structured text.

4. Explore relevant code: The main agent reads the files most relevant to the task to understand the existing architecture, patterns, and constraints. Use Grep/Glob/Read to build context.

Phase 1b: Build Context Packet

After Phase 1 context gathering (reading CLAUDE.md, exploring files, capturing the task), assemble a structured context bundle that will be included verbatim in ALL model prompts. This ensures every model works from the same information.

Write to $SESSION_DIR/context-packet.md (the actual file write happens after Session Directory Initialization in Phase 2 creates $SESSION_DIR):

1. Conventions summary — key rules from CLAUDE.md/AGENTS.md (max 50 lines). Focus on commit format, test patterns, code style, and quality gates relevant to the task.

2. Repo state — branch, HEAD ref, trunk branch, uncommitted changes summary (from context-gather agent results).

3. Changed files — branch changes relative to trunk (from context-gather agent results).

4. Relevant file list — files matching task keywords discovered during Phase 1 exploration. Include paths only, not content.

5. Key snippets — critical function signatures, types, test patterns, or API contracts relevant to the task (max 200 lines). Prioritize interfaces over implementations.

6. Known unknowns — aspects of the task that need discovery during execution. List what the model should investigate.

Size limit: 400 lines total. Prioritize by task relevance. If the packet exceeds 400 lines, truncate the least relevant sections (snippets first, then file list).

Usage in model prompts:

• For the Claude Task agent: reference the file path ($SESSION_DIR/context-packet.md) — the agent reads it directly
• For Antigravity and GPT sub-agents: include the context packet content in the agent prompt, which the sub-agent then passes to the external CLI

For plan, include changed files (branch diff stats), key snippets of code relevant to the task, and known unknowns that the plan should address.

Phase 2: Configuration and Model Detection

Step 1: Parse Flags

Scan $ARGUMENTS for explicit flags anywhere in the text. Flags use --name=value syntax and are stripped from the prompt text before sending to models.

Mode presets set default passes and timeout when not explicitly overridden:

Backward compatibility: Legacy trigger words are silently recognized as aliases:

• multipass (case-insensitive) → --passes=2
• x<N> (N = 2–5, regex \bx([2-5])\b) → --passes=N
• timeout:<seconds> → --timeout=<seconds>
• timeout:none → --timeout=none

Legacy triggers are scanned on the first and last line only (to avoid false positives in pasted content). Explicit -- flags take priority over legacy triggers.

Values above 5 for --passes are capped at 5 with a note to the user.

Config flags (used in Step 2):

• pass_count = parsed pass count from --passes, mode preset, or legacy trigger. Null if not provided.
• timeout_value = parsed timeout from --timeout, mode preset, or legacy trigger. Null if not provided.

Step 2: Interactive Configuration

When flags are provided, skip the corresponding question. When --passes is provided, skip the passes question. When --timeout is provided, skip the timeout question.

If ask-user-choice is unavailable (headless mode via claude -p), use pass_count value if set, otherwise default to 1 pass. Timeout uses timeout_value if set, otherwise the command's default timeout.

Use ask-user-choice to prompt the user for any unresolved settings:

Question 1 — Passes (skipped when --passes was provided):

• question: "How many synthesis passes? Multi-pass re-runs all models with prior results for deeper refinement."
• header: "Passes"
• When pass_count exists (from mode preset or legacy trigger), move the matching option first with "(Recommended)" suffix. Other options follow in ascending order.
• When pass_count is null, use default ordering:
  • "1 — single pass (Recommended)" — Run models once and synthesize. Sufficient for most tasks.
  • "2 — multipass" — One refinement round. Models see prior synthesis and can challenge or deepen it.
  • "3 — triple pass" — Two refinement rounds. Maximum depth, highest token usage.

Question 2 — Timeout (skipped when --timeout was provided):

• question: "Timeout for external model commands?"
• header: "Timeout"
• options:
  • "Default (600s)" — Use this command's built-in default timeout.
  • "Quick — 300s" — For fast queries (0.5× default). May timeout on complex tasks.
  • "Long — 900s" — For complex tasks (1.5× default). Higher wait on failures.
  • "None" — No timeout. Wait indefinitely for each model.

Step 3: Setup Task Agent

After interactive configuration, launch a single setup Task agent (subagent_type: "general-purpose", mode: "default") to perform model detection, timeout detection, and session directory initialization. The main agent passes the resolved pass_count and timeout_value from Steps 1–2, plus the context packet content assembled from Phase 1.

Prompt for the setup agent:

Perform setup for a weave plan session. You have three tasks: detect available models, detect the timeout command, and initialize the session directory.

Input from parent:

• pass_count:
• timeout_value:
• context_packet_content: <full context packet text from Phase 1b>
• task_summary: <first 120 chars of user prompt>
• current_branch: <branch name from Phase 1>
• short_sha: <short SHA from Phase 1>
• trunk_branch: <trunk branch from Phase 1>

Task 1: Detect Available Models

Run these checks:

command -v agy >/dev/null 2>&1 && echo "agy:available" || echo "agy:missing"

command -v gemini >/dev/null 2>&1 && echo "gemini:available" || echo "gemini:missing"

command -v codex >/dev/null 2>&1 && echo "codex:available" || echo "codex:missing"

command -v agent >/dev/null 2>&1 && echo "agent:available" || echo "agent:missing"

Apply model resolution (priority order):

Slot	Priority 1 (native)	Native model	Fallback chain	Agent model
Claude	Always available (this agent)	—	—	—
Antigravity	agy binary	Gemini 3.1 Pro (High)	gemini -m gemini-3-pro-preview → agent --model gemini-3.1-pro	gemini-3.1-pro
GPT	codex binary	(default)	agent --model gpt-5.4-high	gpt-5.4-high

The Antigravity slot is Google's lane: agy (Antigravity) supersedes the standalone gemini CLI, which Google retires on 2026-06-18. agy has no native read-only mode, so read-only commands isolate it in a disposable git worktree (Repo Guard Layer 1; see docs/repo-guard-protocol.md).

Resolution logic for each external slot:

1. Native CLI found → use it
2. Else next CLI in the fallback chain → use it (agent slots use the --model flag)
3. Else → slot unavailable, note in report

Task 2: Detect Timeout Command

command -v timeout >/dev/null 2>&1 && echo "timeout:available" || { command -v gtimeout >/dev/null 2>&1 && echo "gtimeout:available" || echo "timeout:none"; }

On Linux, timeout is available by default. On macOS, gtimeout is available via GNU coreutils. If neither is found, external commands run without a timeout prefix.

Task 3: Initialize Session Directory

Step 1 — Resolve storage root:

if [ -n "$AI_AIP_ROOT" ]; then
  AIP_ROOT="$AI_AIP_ROOT"
elif [ -n "$XDG_STATE_HOME" ]; then
  AIP_ROOT="$XDG_STATE_HOME/ai-aip"
elif [ "$(uname -s)" = "Darwin" ]; then
  AIP_ROOT="$HOME/Library/Application Support/ai-aip"
else
  AIP_ROOT="$HOME/.local/state/ai-aip"
fi

Create a /tmp/ai-aip symlink to the resolved root for backward compatibility:

ln -sfn "$AIP_ROOT" /tmp/ai-aip 2>/dev/null || true

Step 2 — Compute repo identity:

REPO_TOPLEVEL="$(git rev-parse --show-toplevel)"

REPO_SLUG="$(basename "$REPO_TOPLEVEL" | tr '[:upper:]' '[:lower:]' | sed 's/[^a-z0-9._-]/-/g')"

REPO_ORIGIN="$(git remote get-url origin 2>/dev/null || true)"

if [ -n "$REPO_ORIGIN" ]; then
  REPO_KEY="${REPO_ORIGIN}|${REPO_SLUG}"
else
  REPO_KEY="$REPO_TOPLEVEL"
fi

if command -v sha256sum >/dev/null 2>&1; then
  REPO_ID="$(printf '%s' "$REPO_KEY" | sha256sum | cut -c1-12)"
else
  REPO_ID="$(printf '%s' "$REPO_KEY" | shasum -a 256 | cut -c1-12)"
fi

REPO_DIR="${REPO_SLUG}--${REPO_ID}"

Step 3 — Generate session ID:

SESSION_ID="$(date -u '+%Y%m%d-%H%M%SZ')-$$-$(head -c2 /dev/urandom | od -An -tx1 | tr -d ' ')"

Step 4 — Create session directory:

SESSION_DIR="$AIP_ROOT/repos/$REPO_DIR/sessions/plan/$SESSION_ID"

mkdir -p -m 700 "$SESSION_DIR/pass-0001/outputs" "$SESSION_DIR/pass-0001/stderr"

Step 5 — Write repo.json (if missing). If $AIP_ROOT/repos/$REPO_DIR/repo.json does not exist, write it:

{
  "schema_version": 1,
  "slug": "<REPO_SLUG>",
  "id": "<REPO_ID>",
  "toplevel": "<REPO_TOPLEVEL>",
  "origin": "<REPO_ORIGIN or null>"
}

Step 6 — Write session.json (atomic replace). Write to $SESSION_DIR/session.json.tmp, then mv session.json.tmp session.json:

{
  "schema_version": 1,
  "session_id": "<SESSION_ID>",
  "command": "plan",
  "status": "in_progress",
  "branch": "<current branch>",
  "ref": "<short SHA>",
  "worker_backend": "<subagents or model-clis>",
  "participants": ["<participant artifact ID>", "..."],
  "executors": {"<participant artifact ID>": "<executor>"},
  "completed_passes": 0,
  "prompt_summary": "<first 120 chars of user prompt>",
  "created_at": "<ISO 8601 UTC>",
  "updated_at": "<ISO 8601 UTC>"
}

When worker_backend == model-clis, add a "models" array containing the resolved model for each participant. Omit "models" when worker_backend == subagents.

Step 7 — Append events.jsonl. Append one event line to $SESSION_DIR/events.jsonl:

{"event":"session_start","timestamp":"<ISO 8601 UTC>","command":"plan","worker_backend":"<subagents or model-clis>","participants":["<participant artifact ID>","..."]}

Step 8 — Write metadata.md containing: command name, start time, configured pass count, worker backend, participant artifact IDs, executor mapping, resolved models only for model-clis, timeout setting when applicable, git branch, and commit ref.

Step 8b — Repo Guard: Capture fingerprint.

REPO_TOPLEVEL="$(git rev-parse --show-toplevel)"

REPO_HEAD="$(git -C "$REPO_TOPLEVEL" rev-parse HEAD)"

REPO_FINGERPRINT="$(git -C "$REPO_TOPLEVEL" status --porcelain)"

Write $SESSION_DIR/repo-fingerprint.txt containing the HEAD ref and status output.

Step 9 — Write the context packet to $SESSION_DIR/context-packet.md using the content provided above.

Return: SESSION_DIR path, AIP_ROOT, REPO_TOPLEVEL, REPO_DIR, SESSION_ID, available models with their backends (native or agent fallback), timeout command (timeout/gtimeout/empty).

Store $SESSION_DIR and the model/timeout resolution for use in all subsequent phases.

Phase 3: Get Plans from All Models in Parallel

Goal: Ask each model to produce an implementation plan for the task.

Prompt Preparation

Prepend each model's role preamble to its prompt. Each model receives a distinct evaluation lens to decorrelate outputs and reduce shared blind spots. The same context packet is included for all models, but a different role preamble is prepended to each prompt.

Role preambles are prepended before the task-specific prompt and context packet. The role does not change the task — it changes the lens through which the model approaches it.

Include the context packet from Phase 1b. Write the prompt content to $SESSION_DIR/pass-0001/prompt.md via a sub-agent (main agent is in plan mode).

Claude Plan (Task agent)

Launch a Task agent (subagent_type: "general-purpose", mode: "default") to create Claude's plan:

Prompt for the Claude planning agent:

Create a detailed implementation plan for the following task. Read the codebase to understand the existing architecture, patterns, and conventions. Read CLAUDE.md/AGENTS.md for project standards. Read the context packet at $SESSION_DIR/context-packet.md for shared context.

Role: You are the Maintainer. Prioritize correctness, convention adherence, and minimal scope. Challenge any change that isn't strictly necessary. Enforce all project conventions from CLAUDE.md/AGENTS.md.

Task:

Your plan must include:

1. Files to create or modify — list every file with what changes are needed
2. Implementation sequence — ordered steps with dependencies between them
3. Architecture decisions — justify key choices with reference to existing patterns
4. Test strategy — what tests to add/extend, using the project's existing test patterns
5. Risks and edge cases — potential problems and mitigations
6. Commit boundaries — each step should be one atomic commit; include a commit message and note which quality gates to verify before committing (lint, format, type-check, fast tests)

Be specific — reference actual files, functions, and patterns from the codebase. CRITICAL: Do NOT write, edit, create, or delete any files in the repository. Do NOT use Write, Edit, or Bash commands that modify repository files. All session artifacts are written to $SESSION_DIR. This is a READ-ONLY planning task.

Write your plan to $SESSION_DIR/pass-0001/outputs/claude.md.

Antigravity Plan (sub-agent)

Launch a Task agent (subagent_type: "general-purpose", mode: "default") to execute the Antigravity (agy) model and capture its plan.

Prompt for the Antigravity agent:

Run the Antigravity (agy) CLI to generate an implementation plan. You have the following inputs:

• SESSION_DIR:
• Task description:
• Role preamble: "You are the Skeptic. Challenge every assumption. Find edge cases, failure modes, and unstated requirements. Question whether the proposed approach is even the right one. Prioritize what could go wrong."
• Context packet content:
• Backend: <"agy", "gemini", or "agent --model gemini-3.1-pro">
• Timeout command:
• Timeout seconds:

Construct the planning prompt by prepending the role preamble to the task description and context packet, then appending: "Additional instructions: Read AGENTS.md/CLAUDE.md for project conventions. Reference actual files, functions, and patterns from the codebase. Do NOT modify any files — plan only. Include: files to modify, implementation steps in order (each step = one atomic commit with quality gate verification before committing), architecture decisions, test strategy, and risks."

The agent must run the appropriate command based on the backend. Repo Guard: agy has no native read-only mode (its print mode reads and writes), so isolate it in a disposable git worktree checked out at HEAD — agy reads the snapshot while any stray write lands in the throwaway worktree, never the main repo (see docs/repo-guard-protocol.md Layer 1). The gemini and agent fallbacks keep their own native read-only modes.

Primary (agy CLI, disposable worktree):

(AGY_RO_WT="${REPO_TOPLEVEL}-weave-agy-ro"; git -C "$REPO_TOPLEVEL" worktree remove --force "$AGY_RO_WT" 2>/dev/null; git -C "$REPO_TOPLEVEL" worktree add -q --detach "$AGY_RO_WT" HEAD && (cd "$AGY_RO_WT" && <timeout_cmd> <timeout_seconds> agy --model "Gemini 3.1 Pro (High)" --add-dir "$AGY_RO_WT" --dangerously-skip-permissions -p "<prompt>" </dev/null >"$SESSION_DIR/pass-0001/outputs/agy.md" 2>"$SESSION_DIR/pass-0001/stderr/agy.txt"); rc=$?; git -C "$REPO_TOPLEVEL" worktree remove --force "$AGY_RO_WT" 2>/dev/null; exit "$rc")

Fallback (gemini CLI):

(cd "$SESSION_DIR" && <timeout_cmd> <timeout_seconds> gemini -m gemini-3-pro-preview --approval-mode plan --include-directories "$REPO_TOPLEVEL" --skip-trust -p "<prompt>" >"$SESSION_DIR/pass-0001/outputs/agy.md" 2>"$SESSION_DIR/pass-0001/stderr/agy.txt")

Fallback (agent CLI):

(cd "$SESSION_DIR" && <timeout_cmd> <timeout_seconds> agent -p --mode plan --trust --workspace "$REPO_TOPLEVEL" --model gemini-3.1-pro "<prompt>" >"$SESSION_DIR/pass-0001/outputs/agy.md" 2>>"$SESSION_DIR/pass-0001/stderr/agy.txt")

Note: The gemini and agent fallbacks run in their native read-only sandbox (gemini --approval-mode plan, agent --mode plan) pointed at $REPO_TOPLEVEL, so the CLI can read the repo but not write it. The (cd "$SESSION_DIR" && ...) wrapper is a backstop that keeps any escaped write out of the repository. See the Repo Guard Protocol, Layer 1.

Retry and fallback protocol:

1. Record exit code, stderr, elapsed time
2. Classify failure: timeout → retryable with 1.5× timeout; API/rate-limit error → retryable after 10s delay; credit-exhausted → skip retry, escalate to the next backend immediately; crash → not retryable; empty output → retryable once. Detect credit-exhaustion via: RESOURCE_EXHAUSTED, quota exceeded, insufficient_quota, capacity exhausted, usage limit, or HTTP 429 with "daily limit".
3. Max 1 retry with the same backend (skipped for credit-exhausted)
4. If retry fails (or credit-exhausted) AND a native CLI was used, fall back down the chain (agy → gemini → agent), 1 attempt each, same timeout. Append stderr to the same file. If all are credit-exhausted or unavailable, use the lesser model (Gemini 3.5 Flash (High) via agy for Antigravity; gpt-5.4-mini via agent for GPT).
5. After all retries exhausted: mark model as unavailable for this pass
6. Repo Guard: After all CLI attempts complete, capture CURRENT_STATUS="$(git -C "$REPO_TOPLEVEL" status --porcelain)". If $CURRENT_STATUS differs from $REPO_FINGERPRINT, revert with git -C "$REPO_TOPLEVEL" checkout -- . && git -C "$REPO_TOPLEVEL" clean -fd and log the violation: printf '{"event":"repo_guard_violation","timestamp":"%s","model":"agy","reverted":true}\n' "$(date -u '+%Y-%m-%dT%H:%M:%SZ')" >>"$SESSION_DIR/guard-events.jsonl".

Return: success/failure status, output file path, any error details.

GPT Plan (sub-agent)

Launch a Task agent (subagent_type: "general-purpose", mode: "default") to run the resolved GPT-lane CLI and capture its plan.

Prompt for the GPT agent:

Run the resolved GPT-lane CLI to generate an implementation plan. You have the following inputs:

• SESSION_DIR:
• Task description:
• Role preamble: "You are the Builder. Prioritize practical, shippable solutions. Favor simplicity over abstraction. Focus on what gets the job done with the least complexity. Call out over-engineering."
• Context packet content:
• Backend: <"codex" or "agent --model gpt-5.4-high">
• Timeout command:
• Timeout seconds:

Construct the planning prompt by prepending the role preamble to the task description and context packet, then appending: "Additional instructions: Read AGENTS.md/CLAUDE.md for project conventions. Reference actual files, functions, and patterns from the codebase. Do NOT modify any files — plan only. Include: files to modify, implementation steps in order (each step = one atomic commit with quality gate verification before committing), architecture decisions, test strategy, and risks."

The agent must run the appropriate command based on the backend:

Native (codex CLI):

(cd "$SESSION_DIR" && <timeout_cmd> <timeout_seconds> codex exec -s read-only -C "$REPO_TOPLEVEL" --skip-git-repo-check </dev/null \
    -c model_reasoning_effort=medium \
    "<prompt>" >"$SESSION_DIR/pass-0001/outputs/gpt.md" 2>"$SESSION_DIR/pass-0001/stderr/gpt.txt")

Fallback (agent CLI):

(cd "$SESSION_DIR" && <timeout_cmd> <timeout_seconds> agent -p --mode plan --trust --workspace "$REPO_TOPLEVEL" --model gpt-5.4-high "<prompt>" >"$SESSION_DIR/pass-0001/outputs/gpt.md" 2>>"$SESSION_DIR/pass-0001/stderr/gpt.txt")

Note: Each command runs in its native read-only sandbox (codex -s read-only, agent --mode plan) pointed at $REPO_TOPLEVEL, so the CLI can read the repo but not write it. The (cd "$SESSION_DIR" && ...) wrapper is a backstop that keeps any escaped write out of the repository. See the Repo Guard Protocol, Layer 1.

Retry and fallback protocol:

1. Record exit code, stderr, elapsed time
2. Classify failure: timeout → retryable with 1.5× timeout; API/rate-limit error → retryable after 10s delay; credit-exhausted → skip retry, escalate to agent immediately; crash → not retryable; empty output → retryable once. Detect credit-exhaustion via: RESOURCE_EXHAUSTED, quota exceeded, insufficient_quota, capacity exhausted, usage limit, or HTTP 429 with "daily limit".
3. Max 1 retry with the same backend (skipped for credit-exhausted)
4. If retry fails (or credit-exhausted) AND native CLI was used AND agent is available, re-run using the agent fallback command (1 attempt, same timeout). Append stderr to the same file. If agent is also credit-exhausted or unavailable, use lesser model (Gemini 3.5 Flash (High) via agy for Antigravity; gpt-5.4-mini via agent for GPT).
5. After all retries exhausted: mark model as unavailable for this pass
6. Repo Guard: After all CLI attempts complete, capture CURRENT_STATUS="$(git -C "$REPO_TOPLEVEL" status --porcelain)". If $CURRENT_STATUS differs from $REPO_FINGERPRINT, revert with git -C "$REPO_TOPLEVEL" checkout -- . && git -C "$REPO_TOPLEVEL" clean -fd and log the violation: printf '{"event":"repo_guard_violation","timestamp":"%s","model":"gpt","reverted":true}\n' "$(date -u '+%Y-%m-%dT%H:%M:%SZ')" >>"$SESSION_DIR/guard-events.jsonl".

Return: success/failure status, output file path, any error details.

Artifact Capture

Each sub-agent writes its output directly to the session directory:

• Claude: Task agent writes to $SESSION_DIR/pass-0001/outputs/claude.md
• Antigravity: Sub-agent writes to $SESSION_DIR/pass-0001/outputs/agy.md (via CLI stdout redirect)
• GPT: Sub-agent writes to $SESSION_DIR/pass-0001/outputs/gpt.md (via CLI stdout redirect)

Execution Strategy

• Launch all three model agents in the same turn to execute simultaneously.
• If parallel dispatch is unavailable, launch sequentially — the synthesis phase handles partial results.
• Each sub-agent handles its own retry and fallback protocol internally (see agent prompts above).
• After all agents return, the main agent reads the output files from $SESSION_DIR/pass-0001/outputs/ to proceed with synthesis.
• Never block entire workflow on single model failure.

Phase 4: Synthesize the Best Plan

Goal: Combine the strongest elements from all plans into a single, superior plan using evidence-backed adjudication.

The main agent reads the model outputs from $SESSION_DIR/pass-0001/outputs/ (Read is available in plan mode) and performs synthesis.

Blind Judging Protocol

Before synthesis, strip model identity from responses to prevent brand bias during evaluation.

Step 1: Randomize Labels

Assign random labels (Response A, Response B, Response C) to the model outputs. Use a random permutation — do not always assign Claude to A. Record the mapping in $SESSION_DIR/pass-NNNN/label-map.json (via sub-agent):

{
  "A": "<model>",
  "B": "<model>",
  "C": "<model>"
}

Step 2: Evaluate Blindly

During scoring and adjudication (see Synthesis Protocol), refer to responses only by their labels (A/B/C). Do not consider which model produced which output.

Step 3: Reveal After Scoring

After all scoring and adjudication is complete, reveal the model identities in the attribution section of the final report. Include the label mapping so the user can trace which model produced which response.

Limitation: Claude is both participant and judge. True blindness is impossible for Claude's own output — it may recognize its own writing style. The blind labeling primarily prevents bias when evaluating external model outputs against each other.

Synthesis Protocol

After collecting model outputs and applying blind labels, follow this evidence-backed synthesis protocol. The convergence mode for plan is Merge.

Step 1: Verify Claims

For each blinded response (A/B/C), check factual claims against the codebase:

• File references: Use Glob and Read to confirm referenced files exist
• Function/API references: Read the file and verify function signatures, class names, and API contracts match what the response claims
• Convention claims: Check against CLAUDE.md/AGENTS.md — does the response correctly apply project rules?
• Classify each claim: verified (confirmed by reading code), plausible-unverified (reasonable but not checked), or false (contradicted by code)

Write the verification results to $SESSION_DIR/pass-NNNN/verification.md (via sub-agent).

Step 2: Score with Rubric

Rate each blinded response 0–10 per dimension. Use the General Rubric below. Compute a weighted total for each response.

Write scores to $SESSION_DIR/pass-NNNN/scores.md (via sub-agent) in a table showing per-dimension scores and weighted totals for each label (A/B/C).

General Rubric

Step 3: Adjudicate Conflicts

Compare responses to identify:

• Agreement points — all responses concur on these → accept as foundation
• Conflicts — responses disagree → verify against the codebase, accept the one supported by evidence
• Unresolvable conflicts — cannot determine which is correct from code alone → note both positions with available evidence

Step 4: Converge

Build the final result using the Merge convergence mode: Combine agreed points as foundation, apply adjudicated conflict resolutions, incorporate best unique contributions ordered by score, strip unverified claims.

Step 5: Critic

Launch an independent Task agent (subagent_type: "general-purpose") to challenge the synthesized result:

Review the following synthesis for errors. Your job is to BREAK it — find problems, not confirm it's good.

Find: (1) remaining factual errors — file/function references that don't exist, (2) logical inconsistencies — steps that contradict each other, (3) missing edge cases — failure modes not addressed, (4) convention violations — rules from CLAUDE.md/AGENTS.md not followed.

Emit ONLY deltas: each issue found and its specific fix. Do not rewrite the entire synthesis.

Write the critic's findings to $SESSION_DIR/pass-NNNN/critic.md (via sub-agent). Incorporate valid findings into the final output — verify each critic finding against the codebase before accepting it.

Present the plan

Read references/present-results.md and apply it with:

• RESULT_KIND = plan
• ARTIFACT_PATH = $SESSION_DIR/pass-0001/synthesis.md
• SESSION_DIR = $SESSION_DIR
• PASS_COUNT = 1 (or the resolved pass count if multi-pass)
• IN_PLAN_MODE = true
• WORKER_BACKEND = worker_backend
• PARTICIPANTS = the successful participant artifact IDs
• EXECUTORS = the resolved participant artifact ID to executor mapping
• MODELS = resolved models when worker_backend == model-clis; otherwise null
• LABEL_MAP_PATH = $SESSION_DIR/pass-0001/label-map.json

Step 6: Deslop, write to plan file, and persist artifacts

The plan file is the deliverable, so the deslop pass runs before the plan-file write — the plan must land clean.

1. Persist synthesis.md first via sub-agent (subagent_type: "general-purpose", mode: "default"):

   Write the synthesis to $SESSION_DIR/pass-0001/synthesis.md with the following content:

2. Deslop pass (final pass only, skip if --no-deslop). For pass_count == 1, this is the final pass; for pass_count >= 2 the pass runs at the end of Phase 5's last iteration. Read references/deslop-pass.md and apply it with ARTIFACT_PATH=$SESSION_DIR/pass-0001/synthesis.md, SESSION_DIR, the captured BASELINE_SHA, and DESLOP_MODE from the flag. The deslop pass mutates synthesis.md in place and writes a synthesis.pre-deslop.md sibling.

3. Re-read synthesis.md to obtain the desloped plan content.

4. Write the desloped plan content to the Claude plan file directly. This is the plan file write, which IS allowed in plan mode — the plan file is the deliverable.

   The deslop summary block does not appear in the plan body. A single-line confirmation is emitted to the chat instead:

   Desloped (-84 words, 3 trims). Original: <path-to-synthesis.pre-deslop.md>
   

   The full audit lives at $SESSION_DIR/deslop-report.md.

Emit to chat: Plan ready for review.

5. Persist remaining session artifacts via sub-agent:

   • Update session.json via atomic replace: set completed_passes to 1, updated_at to now (ISO 8601 UTC). Write to session.json.tmp then mv session.json.tmp session.json.
   • Append a pass_complete event to events.jsonl: {"event":"pass_complete","timestamp":"<ISO 8601 UTC>","pass":1}
   • Before marking the session as complete, compare the current HEAD and status with the pre-session fingerprint. If either differs, stop and append a non-reverted repo_guard_final violation to $SESSION_DIR/guard-events.jsonl; do not modify the checkout.

Phase 5: Multi-Pass Refinement

If pass_count is 1, skip this phase.

For pass N ≥ 2, do NOT re-run the entire task. Instead, target only:

1. Unresolved conflicts from the prior pass's adjudication (Step 3)
2. Critic findings from the prior pass's critic (Step 5)
3. Low-confidence scores — any dimension scoring < 5 on any response

The main agent reads prior pass artifacts (Read is available in plan mode) to identify refinement targets.

Construct refinement prompts that include ONLY these targeted items:

The following issues remain from the prior pass. Address ONLY these items:

Unresolved conflicts: [list from prior adjudication] Critic findings: [list from prior critic.md] Low-confidence areas: [dimensions/responses that scored < 5]

For each item: provide your resolution with evidence (file paths, line numbers, code references).

For each pass from 2 to pass_count:

1. Create the pass directory via sub-agent (subagent_type: "general-purpose", mode: "default"):

   Create the pass directory and write the refinement prompt:

   mkdir -p -m 700 "$SESSION_DIR/pass-$(printf '%04d' $N)/outputs" "$SESSION_DIR/pass-$(printf '%04d' $N)/stderr"
   

   Write the conflict-only prompt to $SESSION_DIR/pass-{N}/prompt.md with the following content:

2. Re-run all available models in parallel using the same sub-agent dispatch pattern as Phase 3. Launch Claude, Antigravity, and GPT agents with the refinement prompt (same backends, same timeouts, same retry logic). For Claude, reference prior artifacts by path; for external models, inline them.

3. Capture outputs — each sub-agent writes to $SESSION_DIR/pass-{N}/outputs/<model>.md.

4. Re-synthesize following Phase 4 (re-score only affected dimensions, re-adjudicate only targeted disputes).

5. Early-stop check (main agent): Read this pass's synthesis and compare with the prior pass. If no material delta (no scores changed by more than 1, no new conflicts identified), stop refinement early and report convergence.

6. Persist pass artifacts via sub-agent (subagent_type: "general-purpose", mode: "default"):

   Persist pass {N} artifacts:

   • Write synthesis to $SESSION_DIR/pass-{N}/synthesis.md
   • Update session.json via atomic replace: set completed_passes to N, updated_at to now
   • Append pass_complete event to events.jsonl

7. Final-pass deslop: when this is the final pass (last iteration of the loop, or convergence), run Phase 4 Step 6's deslop sub-step on $SESSION_DIR/pass-{N}/synthesis.md before the plan-file write. Gated on --no-deslop exactly as in Phase 4.

8. Update plan file: Write the desloped synthesis to the Claude plan file, adding a Plan Evolution section describing what was strengthened, corrected, or added across passes.

Rules

• Never modify project files — this is project-read-only planning. Session artifacts are written to $AI_AIP_ROOT, which is outside the repository. The Repo Guard Protocol (docs/repo-guard-protocol.md) enforces this: external CLIs run in their native read-only sandbox (Layer 1) — they can read the repo but not write it — post-CLI verification reverts any write that bypasses the sandbox, and session-end verification catches anything else.
• Do not exit plan mode — the plan file is the final output.
• All Bash, Write (non-plan-file), and Edit operations must go through sub-agents spawned with mode: "default".
• Session-end: persist synthesis and update session metadata via sub-agent; write the plan to the plan file directly.
• Always verify each plan's claims by reading the actual codebase
• Always resolve conflicts by checking what the code actually does
• The final plan must follow project conventions from CLAUDE.md/AGENTS.md
• If only Claude is available, still produce a thorough plan and note the limitation
• Use `<timeou

…(truncated)