orchestratelisted

# Orchestrate The root session is the only delegation and integration point. Use the available `planner`, `coder`, and `servant` roles; provider model IDs are runtime-specific and are not a reason to change this behavioral flow. ## Phase 0 — Triage and contract Classify the request. Handle a simple isolated edit or read-only answer directly. For a multi-step task, capture the original request as an acceptance contract before implementation. Ask the user only about a material ambiguity that cannot be safely discovered. Each `[PLAN]` criterion must contain: ``` acceptance_criteria: - id: AC1 criterion: <requirement> user_visible_outcome: <what the user can observe> intended_runtime: <runtime, or "static-only"> verification: <how it will be checked> evidence: <expected artifact or command result> critical: true|false ``` ## Phase 1 — Plan Ask `planner` for a read-only `[PLAN]`. Use `servant` first only when focused repository facts are needed. Resolve material `open_questions` before execution. The plan may use only the existing planner, coder, and servant roles. ## Phase 2 — Plan gate and scope control Check that every original-request outcome has a criterion, intended runtime, and verification. If a proposed action would delete, reduce, substitute, or omit verification of a criterion, emit: ``` [SCOPE_DELTA] affected_criteria: <ids> change: <delete|reduce|substitute|skip-verification> reason: <why> impact: <user-visible consequence> ``` Do