Delegate a bounded task to a Luna worker

Delegate ONE bounded implementation task to an isolated gpt-5.6-luna worker thread.

Use this when a task is well-specified enough to hand off: you can state the objective, what "done" looks like, and which files may change. Keep architecture, sequencing, and final judgement for yourself.

Choosing effort — rate THIS TASK's intrinsic difficulty, never the parent project's importance: medium Mechanical and fully specified. Rename, move, boilerplate, obvious test cases, applying a pattern that already exists in the codebase. high DEFAULT. Real implementation work needing judgement within one area: a new endpoint, a bug fix with a known repro, a focused refactor. xhigh Subtle or cross-cutting. Concurrency, tricky state, non-obvious performance work, changes rippling across several modules, or a bug whose cause is not yet identified. max Genuinely hard problems only. Reserve for tasks where a strong engineer would expect to be stuck for a while: intricate algorithms, deep debugging with no clear lead, or a task that already came back FAILED at xhigh. An important task that is straightforward is still "high" — importance is not difficulty.

Prefer escalating over starting high: run at high, and if it comes back FAILED because the task was genuinely hard, re-delegate at xhigh with previousAttempts filled in. If it failed because your brief was vague, fix the brief instead — the same objective at higher effort usually fails again, slower.

BEFORE delegating at all, decide whether it is worth it. Delegation has a fixed overhead — writing the contract, spawning a thread, re-verifying the result — and on small work that overhead exceeds the work itself. Measured on this project's own micro-benchmark, delegating a one-file task was ~2.3x slower and ~3.5x the tokens of just doing it, with no quality difference.

Do it yourself when:

• the change is small, mechanical, or confined to one file

• you already know the exact edit

• explaining the task would take longer than making the change

• there is no second independent piece of work to overlap it with

Delegate a single task when the work is substantial and bounded, and you want an enforced file scope plus independently re-run verification.

For two or more independent pieces of work, use delegate_tasks instead — that is where delegation can actually save wall-clock time.

The worker cannot delegate further and cannot see this conversation.

The result is evidence, not a conclusion. The orchestrator independently re-runs your verificationCommands after the worker exits and checks which files were actually touched, then returns verdict, discrepancies, and reviewChecklist. A worker PASS with a FAILED verdict means the worker was wrong. Always review the diff before accepting.

verificationCommands run without a shell: one allowlisted executable per command, no pipes, redirects, && or ;. Use npm test or pytest -q, not npm run build && npm test (pass those as two commands).