Issue Batch

---
description: Launch-and-go continuous issue-processing cycle — a replace-on-completion pipeline of 6-8 lean-clone background agents, fire-and-forget merge, disk-gated spawn, release checkpoint per iteration.
---

# /issue-batch — SceneView continuous issue cycle

You are the **orchestrator** of SceneView's continuous issue-processing cycle. Your
job is to **audit, dispatch, and monitor — never to code yourself**. A maintainer
starts a session, says "run the cycle", and you keep a steady pipeline of background
agents flowing until the backlog is drained or they ask you to stop.

> **Executable form.** The mechanical per-issue loop is now the **`fix-issue-batch`
> saved workflow** (`Workflow({ name: "fix-issue-batch" })` → `.claude/workflows/fix-issue-batch.js`):
> claim → lean-clone → fix → self-review → fire-and-forget merge → release-claim, with
> `claim.sh` killing the #2300 race. This skill is the orchestrator's *playbook* (the
> *why*, plus the audit + release-checkpoint wrapping); the workflow is the *how* for the
> fan-out. Run the workflow for the loop; use `audit-sweep` / `release-checkpoint` workflows
> for those phases.

The validated operating model (formalized 2026-05-15; rigor layer added 2026-06-02) is:

AUDIT → AUTO-FILE → BATCH → DISPATCH └─ worker: CHALLENGE (disprove the issue's prescribed root cause with a probe BEFORE coding) → fix → Tier-1 self-review → open PR └─ SCOPE-GRADED REVIEW: trivial = self-review DECLARED in the PR body + fire-and-forget; medium+ / public-API / rendering / threading = orchestrator runs the review-fanout workflow (4 adversarial reviewers) └─ GRADED MERGE: auto-merge UNLESS a confirmed ERROR survives, REVIEW_INCOMPLETE, or a BREAKING public-API change (impact gate → draft PR + stop for maintainer) → re-AUDIT

See **"Challenge · graded review · graded-merge autonomy"** below for the rigor layer.
The autonomy is deliberately *high* here because SceneView is the maintainer's own
low-personal-risk repo: auto-merge on **all** platforms,
the challenge is **self-decided** by the worker (no per-issue human gate), and the maintainer
is surfaced ONLY for a breaking public-API change, a cross-cutting design call, or a revert.

**Master playbook:** the full rationale lives in agent memory
`feedback_continuous_issue_cycle.md`. Supporting detail: `feedback_issue_workflow.md`
(Rapporteur/Correcteur split), `feedback_pr_review_workflow.md` (Tier 1 / Tier 2),
`feedback_resource_hygiene.md` (disk gating). Read those for the *why*; this file is
the *how* — keep it as the executable checklist.

⛔ **Harness limitation (issue #1243)** — background agents launched via `spawn_task`
or `Agent(isolation="worktree")` **cannot spawn nested `Agent()` reviewers**. The
harness silently rejects nested calls. So real multi-agent review only happens at the
**orchestrator level** (Tier 2). Each background agent does a single self-review pass
(Tier 1).

---

## Core operating rules (the launch-and-go contract)

1. **Pipeline, not waves.** Keep **6-8 background agents running at all times**.
   The moment one signals done, immediately dispatch the next batch into the freed
   slot — no idle gap waiting for a whole wave to finish.
2. **Disjoint modules only.** Concurrent agents must touch non-overlapping module
   trees: `sceneview/` ≠ `arsceneview/` ≠ `sceneview-core/` ≠ `samples/ios-demo/` ≠
   `samples/android-demo/` ≠ `mcp/` ≠ `sceneview-web/` ≠ `.github/workflows/` ≠
   `docs/`. If two ready batches collide, serialize them.
3. **Lean clone per agent.** Every agent works in its OWN shallow sparse clone and
   deletes it on exit. A full clone is ~2.3 GB; a lean one is ~0.3-0.6 GB — this is
   the disk-bloat fix. See the agent brief template below.
4. **Disk-gated spawn.** Before spawning, check free disk. **Refuse to spawn a new
   agent if free space < 15 GB** — wait for an in-flight agent to return and clean
   up first. (`df -g / | tail -1`.)
5. **Fire-and-forget merge.** Each agent pushes, opens its PR, runs
   `gh pr merge --squash --auto`, then exits. It does **not** sit watching CI. The
   orchestrator monitors for stuck PRs (see Phase 4).
6. **Release checkpoint each iteration.** At the end of every cycle iteration, run a
   release checkpoint (`/release` or `release-checklist.sh`). **Semver is capped at
   minor — major `4` is frozen** (cf. `feedback_version_policy.md`). v5 is a
   deliberate milestone, never an auto-bump.
7. **Autonomous dispatch; consult only on non-trivial decisions.** Routine batching
   and dispatch needs no approval. Pause and ask the maintainer only for: scope
   ambiguity, breaking-change strategy, a revert, or a cross-cutting design call.
8. **Verify before dispatch.** Confirm each issue is still OPEN and not already
   fixed on `main`. Stale issues are common — don't dispatch a no-op batch.
9. **Auto-file everything.** Every finding — maintainer remark, in-passing
   discovery, Tier-2 result — becomes a GitHub issue immediately. Track in GitHub,
   never just remember.

---

## Challenge · graded review · graded-merge autonomy  (the rigor layer)

A rigor layer calibrated for SceneView's deliberately high autonomy.
Three additions make the autonomous fire-and-forget loop *safe*:

### A. Challenge BEFORE coding — disprove the prescribed root cause
The issue's stated root cause is **often wrong** (proven repeatedly — `feedback_reproduce_before_prescribed_fix`; this is why #2354 avoided a needless Earcut port and #2361 avoided an uncompilable `key=` fix). Every worker, before writing any fix:
1. **Staleness + race gate (cheapest, highest-ROI):** `git fetch origin` + `git log --oneline HEAD..origin/main`; read the diffs of recently-merged PRs that touched the files in scope; `claim.sh` for the cross-host race. If a merged/in-flight PR already resolved or obsoleted it → close as already-resolved + skip. A title-only PR scan is NOT enough.
2. **R