lane-planner.prose.md

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, 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.