Luna Local Review Loop

Use native host collaboration when its complete lifecycle capability set is available. Use bundled scripts as the deterministic codex exec fallback only. Read README.md before first use.

Roles

Parent owns decomposition, permissions, durable goals/plans, validation judgment, review, commits, delivery, CI, and GitHub state. Worker owns exactly one immutable task and is the sole worker for that task. Worker performs its scope directly and never spawns, delegates to, or hands work to another subagent. Worker never stages, commits, pushes, reviews combined changes, manages GitHub/CI, daemonizes, double-forks, or starts persistent background services.

Both roles read target repository AGENTS.md hierarchy and project-local .agents/skills/caveman/SKILL.md. Use project-local Caveman for user-facing output. The parent orchestrates each code-reviewer pass through a fresh Sol-High reviewer and retains the final review decision.

Select execution path

The parent/controller is model-agnostic. This skill never names, pins, or implies a concrete parent model or reasoning setting.

Use native host collaboration only when the host exposes the complete lifecycle contract: spawn, unique task identity, message/follow-up, wait, interruption/close, list/read/collect, and the atomic cross-path claim primitive. The pre-start capability result must also prove exact model selection, exact reasoning selection, and an enforceable read-only or sandbox control for both implementation and review roles. Select this from the host capability result, never from shell or environment guesses.

Implementation and validation workers always use a fresh Luna Max worker: model gpt-5.6-luna, reasoning max, and the smallest useful context. Every code-review pass and re-review always uses a fresh, read-only Sol-High reviewer: model gpt-5.6-sol, reasoning high. The parent evaluates the review and owns the final decision; the parent model is not a substitute reviewer.

Record the selected path and the exact worker/reviewer configuration in the parent-owned evidence. Before selecting native, the parent performs a read-only fallback-ownership preflight: after validating the canonical repository and registry authority, a missing project-local fallback registry is recorded as not-initialized (a clear ownership state); when it exists, inspect its active workers for the repository and immutable scope. An active or awaiting-continue fallback task pins that scope to its existing CLI task until it is retired. A malformed, unreadable, ambiguous, or conflicting fallback state is a parent-action stop. Immediately after this preflight and before native spawn, the parent acquires an atomic host-owned cross-path claim keyed by canonical physical checkout identity and immutable scope. The fallback launcher uses that same claim before its registry reservation: run-worker.sh launch explicitly invokes --reenter-or-acquire with stable token task-$TASK_ID, so it re-enters a parent-held same-owner claim or acquires a missing claim atomically. The claim is separate from the fallback registry, is held through the selected native or CLI lifecycle and cleanup, and is released only after the owner is terminal. A non-terminal CLI checkpoint retains the claim; a same-owner continuation re-enters it with the stable task identity before resuming. Native never creates, reads, or writes fallback registry state. If the claim is unavailable or conflicts, stop with parent action before either path starts. This claim closes the check-then-start race between native startup and fallback reservation. If native startup has begun and then fails, stop with an explicit failure; do not silently switch paths. Use the CLI fallback only when the complete native capability set was unavailable before startup and the fallback review gate and cross-path claim are recorded.