/warren-dogfood-pipeline

name: warren-dogfood-pipeline
description: Full prioritize → dispatch → shepherd → track pipeline against the live warren instance. Audits the seeds backlog around a focus theme, dispatches the surviving issues to warren agents one at a time, babysits the resulting PRs to merge (update-branch, conflict-repair runs, auto-merge), and closes the loop in the tracker. Activate for prompts like "run the dogfood pipeline", "dispatch the P1 <theme> issues to warren", "audit and dispatch", "work the backlog through warren agents".

Protocol: Warren Dogfood Dispatch Pipeline

You run a themed slice of the seeds backlog end-to-end through the live warren instance: audit → ordered dispatch list → sequential runs → PR shepherding → tracker closure. Every run on the public instance is also demo content, so prefer dispatching warren runs over doing the work locally — including for repairs. The pipeline was proven 2026-07-28 (deletion pass: 9 issues, 15 runs, PRs #650–#658, plan pl-3a79 closed).

0. Inputs (ask if not given)

• **Focus theme + priority band** — e.g. "P0/P1 deletion-focused",

"security leaks", "docs drift". This drives the audit lens.

• **Agent + model/provider** — ALWAYS stop and ask the operator

(AskUserQuestion) which model + provider to use for all tasks in the session, even when every other input was given. Recommended default: provider `openrouter`, model `moonshotai/kimi-k3`, on the `pi` harness (the only harness that can reach OpenRouter; it is also the project `defaultRole`). Offer the anthropic tiers (`src/registry/builtins/model-tiers.ts`) as alternatives — for hard or large refactors use `claude-opus-5` (Opus 5; pass it as an explicit `modelOverride` — do NOT rely on the opus tier's default, which still pins the older claude-opus-4-8). Dispatch with explicit `providerOverride` + `modelOverride` matching the answer.

• **Dispatch mode** — sequential one-at-a-time (default, what the

operator chose last time) vs parallel. Sequential means: next issue run dispatches only after the previous run is TERMINAL; repair runs are exempt and may overlap.

• **Blocked issues** — skip them, or dispatch their blockers first

(last time: blockers first).

Report your understanding and the candidate list BEFORE dispatching anything. Dispatching costs real money and opens real PRs.

1. Phase 1 — Audit & prioritize (subagent)

Spawn a subagent that invokes the `seeds-issue-audit` skill, with an extra deliverable bolted on: a **DELETION-DISPATCH-LIST-style section** for the focus theme — every still-open, in-theme issue with LIVE blocker resolution (a closed blocker doesn't count; re-check each edge) and a serial dispatch order, blockers first, sequenced so each run can build on the previous merge. Require the exact line format `<order>. <id> — <title> — <UNBLOCKED | blocked-by: ids>` so you can dispatch straight off it.

Babysit the subagent: if it stops claiming to "wait for a worker notification" while it has no live children, resume it and tell it to finish the batch inline.

2. Phase 2 — Dispatch plumbing

• **Instance**: hostname lives only in the gitignored

`deploy/k8s/overlays/gke-live/kustomization.yaml` (Ingress host patch). Token: `kubectl get secret warren-secrets -n warren -o jsonpath='{.data.warren-api-token}' | base64 -d` (key is `warren-api-token`, not `WARREN_API_TOKEN`).

• **Project id**: `GET /projects`, match the gitUrl.
• **Dispatch**: `POST /runs` with `{agent, project, prompt,

modelOverride, seedId}`. Always pass `seedId` — it links the run to the tracker. Response shapes differ: `POST /runs` WRAPS the run (`{run: {...}}`), while `GET /runs/:id` returns it BARE — parsing the POST as bare reads all-null and invites a duplicate dispatch. Terminal states are `succeeded|failed|cancelled`.

• **Repair dispatch onto an existing PR branch**: same POST with

`ref` = `targetBranch` = the PR's head branch. Warren pushes back to that branch in place; the agent must NOT open a new PR or branch.

**Prompt template per issue run** (adapt, keep all five elements): 1. "Work seeds issue <id>. First run `sd show <id> --json` from the repo root" — the issue body is the spec; your summary is a digest. 2. Context of what already merged on main that this run builds on. 3. Scope guidance (what to delete/change; repo-specific gotchas like `bun run check:bundle-size --update` for UI work). 4. "Quality gates are terminal: `bun run check:all` must be green before you commit and report done." 5. "Close the issue with `sd close <id> --reason ...`, then commit everything."

**Polling**: background loop, ~55s interval, ≤10 iterations per loop (re-launch on expiry). Pipe curl straight into the JSON parser — never round-trip response bodies through a shell variable + `echo` (zsh echo expands `\n` inside the JSON and corrupts it). On terminal, capture `state`, `failureReason`, `prUrl`, `costUsd`.

3. Phase 3 — Sequential loop with merge gates

• Next **independent** issue dispatches when the previous run is

terminal.

• A **dependent** issue dispatches only when every blocker's PR is

**MERGED on main** (re-verify with `gh pr view <n> --json state` immediately before dispatch) — a terminal run is not enough; the next clone needs the code.

• Interleave: put independent issues between a blocker and its

dependents so PRs have time to merge while other work runs.

4. PR shepherding (expect to do this for EVERY PR)

Themed slices touch overlapping files (CLAUDE.md, budgets, `.seeds/issues.jsonl`), so almost every PR that outlives another merge goes stale. Diagnose with `gh pr view <n> --json mergeable,mergeStateStatus,autoMergeRequest,statusCheckRollup`:

| State | Fix | | --- | --- | | `BEHIND`, auto-merge armed | `gh pr update-branch <n>` (re-run after every upstream merge — serial auto-merge is a chase) | | `DIRTY` (conflicts) | dispatch a **repair run** on the PR branch (below) | | `CLEAN`/green but auto-merge off | A