Sol-Luna Router

Sol-Luna Router

Keep Sol responsible for decisions and final verification. Use Luna Max for one bounded implementation or read-only investigation. Use the bundled runner instead of native spawn_agent; current Sol and Luna releases can select different multi-agent backends.

Boundaries

• Distinguish Skill activation from worker dispatch: inspect router configuration, usage, telemetry, and efficiency questions read-only without launching Luna; keep small or straightforward tasks Sol-only unless the user explicitly requests Luna; launch Luna only for explicit delegation or when isolated, auditable two-stage execution is substantively needed.
• Treat the current Sol thread as commander and reviewer. Do not edit target product files from this thread.
• Delegate concrete implementation, fixes, worker-owned tests, or bounded read-only investigation to Luna Max.
• Fix every new and resumed worker invocation to gpt-5.6-luna with reasoning effort max.
• Allow only one write-capable Luna worker in a worktree at a time. Parallelize read-only work, or use isolated worktrees with explicit, disjoint file ownership.
• Keep the parent approval and sandbox boundary intact. Never add bypass, full-access, force-push, credential, or secret-handling flags.
• For delegated coding tasks, fix Apps, Plugins, and recommended-plugin context off for every worker run and resume so the task stays self-contained. Keep --strict-config fail closed; report a stale user configuration as config_incompatible and fix it instead of bypassing it.
• Stop after three failed correction cycles on the same root cause and reassess the hypothesis.
• Never claim completion from the worker summary alone. Verify from the current session.
• Do not use worker timeout as a test budget. Select a profile and give every potentially expensive command an explicit bound before launch.
• Keep the commander thin: do not duplicate Luna's repository scan or implementation analysis; launch one bounded worker, collect one result, and combine independent verification commands into the smallest safe check. Resume only from concrete failed evidence.

Operating Contract

• Direct actions: inspect local state, create external task prompts, run Luna within scope, and perform read-only verification.
• Escalate before: expanding ownership or permissions, using new network or credentials, destructive recovery, publishing, pushing, merging, or changing products.
• Evidence-backed pushback: cite a diff, command, repository rule, run record, or capacity failure when the requested route is unsafe or cannot satisfy done-when conditions.
• Feedback loop: use aggregate ledger evidence and correction patterns for the smallest runner, test, profile, or gotcha update; never optimize from token totals alone.