# Native agent dispatch Use this contract whenever orchestrated mode has two or more independent `READY` leaves. Unlazy records native launches; the host creates the agent sessions. For one wave, every native launch call and every `start` record must finish before the first wait, join, result read, or return record. ## Open and seal a launch wave Claim every leaf first. Partition more `READY` leaves into later waves when they exceed the host's current concurrency limit. Then open one wave with the exact ids: ```text node /scripts/dispatch-check.mjs open --scope --wave ready-1 --leaf leaf-1.1.1 --leaf leaf-1.1.2 ``` For each leaf, call the host's native nonblocking launch tool and record the opaque, nonsecret handle it returns: ```text node /scripts/dispatch-check.mjs start --scope --wave ready-1 --leaf leaf-1.1.1 --handle node /scripts/dispatch-check.mjs start --scope --wave ready-1 --leaf leaf-1.1.2 --handle ``` Seal the wave before waiting for any result: ```text node /scripts/dispatch-check.mjs seal --scope --wave ready-1 ``` Seal fails until every declared leaf has a distinct start handle. `return` fails before seal. These refusals catch the serial pattern where a driver launches one leaf, waits for it, and only then launches the next. When a native agent finishes, record the return before parent re-verification: ```text node /scripts/dispatch-check.mjs return --scope --wave ready-1 --leaf leaf-1.1.1 ``` A return records scheduler completion, including a failed worker result. It does not mark the leaf `VERIFIED`; the parent still runs the leaf gates and reviews manual evidence. Check the finished wave with: ```text node /scripts/dispatch-check.mjs status --scope --wave ready-1 ``` `status` exits `0` only after every declared leaf returned. Dispatch state and timestamps live in `.unlazy//dispatch.json`; lifecycle events also append to the scope status log. The state loader requires string ids, handles, and abandonment reasons plus a possible transition history: returns require an all-started sealed wave, terminal timestamps must exist and follow prior transitions, and a fully returned wave must be complete. Hand-editing an impossible terminal state fails closed. The primary `gate-check.mjs --scope ` reduction includes this aggregate state and cannot print `ALL MET` while a wave is open, sealed, abandoned, or invalid. ## Selesai launch adapter Use the native `subagent` tool. Launch each leaf as one async child and record the returned run id as the handle. Follow the same barrier: schedule the whole fan-out before collecting its first result. ```text # open the wave with dispatch-check (step above) # then, per leaf, launch one async subagent run and record its run id: subagent({ agent: "worker", task: leafBrief, async: true }) # -> returns a run id node /scripts/dispatch-check.mjs start --scope --wave ready-1 --leaf leaf-1.1.1 --handle node /scripts/dispatch-check.mjs seal --scope --wave ready-1 # only after seal: wait for results (async completion notifies the session natively; # use bg_wait only for provider/detached work without a native notification) # per returned leaf: node /scripts/dispatch-check.mjs return --scope ... --leaf ... ``` Do not use `subagent({ action: "list" })` scheduling tricks or a shell process farm as a substitute; keep each leaf an owned, observable async run. A worker's own subagent fanout is bounded by the child tool allowlist; unlazy waves are driven from the parent. ## Failure and fallback If a native launch fails before returning a handle, leave the wave open, fix the launch problem, and retry that leaf. Do not seal a partial wave. If recovery is impossible, preserve the audit trail instead of inventing a handle or deleting state: ```text node /scripts/dispatch-check.mjs abandon --scope --wave ready-1 --reason "" ``` An abandoned wave is terminal and `status` exits `1` and the aggregate scope reduction prints `HANDOFF REQUIRED` until the reason is surfaced in the final report. If the host has no nonblocking launch capability, record the limitation in `PLAN.md`, execute a declared sequential fallback, and do not open or describe a parallel wave. Opening a wave is an execution claim. Do not invent handles, record a foreground result as a start, or call simultaneous work proved merely because commands ran quickly. ## Evidence boundary The launch barrier proves that the host accepted every native start before the driver accepted a return. It does not prove worker honesty, exact CPU overlap, filesystem isolation, or successful integration. Leases, parent re-verification, and branch gates remain separate requirements.