---
name: lane-planner
kind: service
---

# Lane Planner

### Description

Choose reviewer and validator lanes from discovered runner capabilities and
candidate model IDs.

### Requires

- `brief`: review brief
- `runner_capabilities`: capability report with exact candidate model IDs
- `preferences`: optional run guidance

### Ensures

- `lane_plan`: Markdown lane plan with active and skipped lanes, exact runner
  invocation profile, exact candidate model ID, model family, focus, validator
  profile, safety class, workspace-copy needs, and reason. The plan includes
  at least one validator invocation for each active reviewer lane.

### Errors

- `no-eligible-lanes`: no runner is usable under current preferences

### Shape

- `self`: pick lanes for independent model-family coverage and fail closed on
  safety
- `prohibited`: using prompt-only safety by default, inventing models, querying
  model lists, delegating lane planning to reviewer or validator runners,
  hiding skipped lanes, or treating provider diversity as model-family
  diversity

### Strategies

- Safety classes: `read-only-capable`, `best-effort-read-only`, `prompt-only`,
  `unknown`, `unsafe`.
- When choosing model-family diversity, read `references/model-families.md`.
- Choose only exact candidate model IDs reported by `runner-discovery`. If a
  preferred family is not in the roster, skip it rather than fabricating a model
  target or querying model lists directly.
- Eligible by default: `read-only-capable` and `best-effort-read-only`.
- Plain `crush run` is `read-only-capable`; `crush run --yolo` is
  `best-effort-read-only` and must be disclosed.
- Skip by default: ordinary Pi, prompt-only, unknown, and unsafe profiles.
- Partition work by distinct surfaces or bug classes so lanes do not converge:
  changed component, entry point, protocol stage, trust boundary, or one
  narrowly named vulnerability class.
- Keep prompts compact. Give goal, context, focus, bug bar, output shape, and a
  few high-value false positives to skip; avoid dumping a large checklist.
- When the brief identifies LLM, agentic, RAG, MCP, or tool-calling behavior,
  include a lane for the relevant prompt/tool/data boundary.
- Plan validators separately from reviewers. For every active reviewer lane,
  assign at least one validator invocation. Prefer a validator model family not
  used for that reviewer lane, and give validators neutral candidate briefs
  plus fresh workspace copies.
- The minimum is invocation cardinality, not necessarily distinct validator
  models: if only one eligible validator profile exists, reuse it in separate
  validator invocations and disclose the reuse.
- Prefer open-weight families: Qwen, GLM, Kimi, MiniMax, Mimo, DeepSeek.
- If there are multiple eligible Prose Complete harnesses, diversify both model
  families and the harnesses/runners they're running in.
- Emit exact lane order. Candidate IDs later follow this order.