docs(mobile): reviewer loop, Opus 4.8 orchestrator, and pre-plan bug repro gate

[iscekic]

What

Three changes to apps/mobile/.kilo/MOBILE_WORKFLOW.md:

1. Generalize the Kilobot/CI loop to all reviewers. The "Kilobot and CI Loop" section is now "Reviewer and CI Loop": triage, repair, in-thread replies, and thread resolution explicitly apply to review comments from any reviewer (Kilobot, other bots, humans). Step 10 now states that a fix without its in-thread reply and thread resolution is not done, and the completion gate requires every addressed finding to have a reply and a resolved thread.
2. Orchestrator model → Claude Opus 4.8 (high). The planner-handoff launch command and its accompanying instruction now use kilo/anthropic/claude-opus-4.8 --variant high (prompt caching verified healthy on this slug).
3. Bug reproduction gate for defect work. Planning now creates worktrees first and, for defect work, dispatches a fresh mobile-e2e-verifier in repro mode on the unmodified baseline before the draft plan is written. A confirmed repro feeds the plan (root-cause hypothesis, repro-flow-passes acceptance criterion, resource manifest in the handoff); cannot reproduce is a blocker — hands-on asks the user, hands-off stops with a blocker report instead of fixing an unconfirmed bug. The verifier agent definition gains a matching repro-mode paragraph (--phase prewarm, honest cannot reproduce outcome, never fix or route around the defect).

[kilo-code-bot]

Code Review Summary

Status: No Issues Found | Recommendation: Merge

Executive Summary

The latest commit (08a7ba2) adds a pre-plan bug reproduction gate for defect work, renumbering the Planning steps and updating the mobile-e2e-verifier role description and handoff requirements consistently across both changed files, with no broken step references or internal contradictions.

Files Reviewed (2 files)

• apps/mobile/.kilo/MOBILE_WORKFLOW.md
• apps/mobile/.kilo/agent/mobile-e2e-verifier.md

Previous Review Summaries (6 snapshots, latest commit e50ed1b)

Current summary above is authoritative. Previous snapshots are kept for context only.

Previous review (commit e50ed1b)

Status: No Issues Found | Recommendation: Merge

Executive Summary

Commit e50ed1b resolves the previously flagged contradiction by scoping the count-based "three consecutive rounds" plan-gate floor explicitly to plan-text disagreement between planner and reviewer, while stating that delegated implementation work follows the escalation ladder instead.

Files Reviewed (1 file)

• apps/mobile/.kilo/MOBILE_WORKFLOW.md

Previous review (commit 3124c73)

Status: 1 Issue Found | Recommendation: Address before merge

Executive Summary

The retained "three consecutive rounds" count-based takeover trigger in the Planner Handoff section still contradicts the "Escalation ladder, not takeover-by-count" policy; this latest commit did not touch that line.

Overview

Severity	Count
CRITICAL	0
WARNING	1
SUGGESTION	0

Issue Details (click to expand)

WARNING

File	Line	Issue
apps/mobile/.kilo/MOBILE_WORKFLOW.md	60	Count-based repair-round limit ("three consecutive rounds") contradicts the escalation-ladder policy, which rejects takeover-by-count in favor of a zero-progress trigger

Files Reviewed (1 file)

• apps/mobile/.kilo/MOBILE_WORKFLOW.md - 1 issue

Fix these issues in Kilo Cloud

Previous review (commit 17d1f78)

Status: 1 Issue Found | Recommendation: Address before merge

Executive Summary

The new "Escalation ladder, not takeover-by-count" rule in apps/mobile/.kilo/MOBILE_WORKFLOW.md is contradicted by the retained "three consecutive rounds" count-based takeover trigger in the Planner Handoff section.

Overview

Severity	Count
CRITICAL	0
WARNING	1
SUGGESTION	0

Issue Details (click to expand)

WARNING

File	Line	Issue
apps/mobile/.kilo/MOBILE_WORKFLOW.md	60	Count-based repair-round limit ("three consecutive rounds") contradicts the new escalation-ladder policy, which rejects takeover-by-count in favor of a zero-progress trigger

Files Reviewed (1 file)

• apps/mobile/.kilo/MOBILE_WORKFLOW.md - 1 issue

Fix these issues in Kilo Cloud

Previous review (commit 64f6bfd)

Status: No Issues Found | Recommendation: Merge

Executive Summary

Commit 64f6bfd adds a Kilobot crash-recovery instruction to step 9 (retrigger via empty commit or PR-comment re-review request, then resume waiting); the addition is internally consistent with the rest of the reviewer/CI loop and introduces no new issues.

Files Reviewed (1 file)

• apps/mobile/.kilo/MOBILE_WORKFLOW.md

Previous review (commit 77ad76e)

Status: No Issues Found | Recommendation: Merge

Executive Summary

Commit 77ad76e resolves the prior wait/completion-gate inconsistency by explicitly stating in all four locations that Kilobot is the only reviewer waited for, while other reviewers' already-posted comments still get full triage, repair, reply, and resolve treatment.

Files Reviewed (1 file)

• apps/mobile/.kilo/MOBILE_WORKFLOW.md

Previous review (commit 1458699)

Status: 3 Issues Found | Recommendation: Address before merge

Executive Summary

The reviewer/CI loop's wait and completion conditions still reference "Kilobot has reviewed the latest head" specifically, while the surrounding text and comment-triage steps were generalized to cover every reviewer, creating an internal inconsistency in apps/mobile/.kilo/MOBILE_WORKFLOW.md.

Overview

Severity	Count
CRITICAL	0
WARNING	3
SUGGESTION	0

Issue Details (click to expand)

WARNING

File	Line	Issue
apps/mobile/.kilo/MOBILE_WORKFLOW.md	126	Step 9 wait condition still gates on Kilobot only, not "every reviewer"
apps/mobile/.kilo/MOBILE_WORKFLOW.md	128	Step 11 repeat condition still keyed to Kilobot's review only
apps/mobile/.kilo/MOBILE_WORKFLOW.md	175	Completion gate still requires only Kilobot's review, not every reviewer's

Files Reviewed (1 file)

• apps/mobile/.kilo/MOBILE_WORKFLOW.md - 3 issues

Fix these issues in Kilo Cloud

---

_{Reviewed by claude-sonnet-5 · Input: 38 · Output: 7.4K · Cached: 982.1K}

_{Review guidance: REVIEW.md from base branch main}