Fleet Dispatch Gate

The 4-Check Protocol

Check 1: Is the target node online and has an active session?

Query the fleet daemon for node status before dispatching anything.

# Check node health via daemon
curl -sf http://127.0.0.1:8855/status | python3 -c "
import sys, json
status = json.load(sys.stdin)
for node in status.get('nodes', []):
    print(f\"{node['id']}: online={node.get('online', False)} session={node.get('session_active', False)}\")
"

# Or via NATS heartbeat check
nats sub 'fleet.heartbeat.TARGET_NODE' --count=1 --timeout=5s

If target is offline: GATE FAILS. Do not dispatch. Options:

• Wake the node first (fleet-wake) and re-check
• Queue the task for later delivery
• Execute locally instead

If target has no active session: GATE FAILS for interactive tasks. Background tasks may still proceed if the daemon can handle them without a Claude session.

Check 2: Is the task appropriate for remote execution?

Not all work belongs on a remote node. Evaluate:

If the task requires local resources or shared state: GATE FAILS. Execute locally.

Check 3: Could this task conflict with work the target is doing?

Check the target node's current activity before dispatching competing work.

# Check what the target is currently working on
curl -sf http://127.0.0.1:8855/status | python3 -c "
import sys, json
status = json.load(sys.stdin)
for node in status.get('nodes', []):
    if node['id'] == 'TARGET_NODE':
        print(f\"Current task: {node.get('current_task', 'idle')}\")
        print(f\"Focus: {node.get('focus', 'none')}\")
"

Conflict indicators:

• Target is editing files your task also needs to edit
• Target is on the same git branch your task will modify
• Target is running tests that your task's changes would invalidate
• Target is mid-implementation on a dependent component

If conflict detected: GATE FAILS. Options:

• Wait for current work to complete
• Coordinate sequencing (target finishes first, then your dispatch)
• Redesign the task to avoid overlapping files/branches

Check 4: Is the task reversible if it fails?

Every remote dispatch must have a rollback path. Remote failures are harder to diagnose and recover from than local ones.

If task is not reversible: GATE FAILS. Execute locally where you can monitor and intervene.

Emergency Bypass Protocol

For urgent fleet operations (node is about to lose work, connectivity window closing):

1. Declare emergency — state what is urgent and why bypass is needed
2. Dispatch with monitoring — send the task but actively monitor via fleet-watchdog
3. Post-dispatch verification — run fleet-post-verification immediately after completion
4. Log the bypass — record why the gate was bypassed for future reference

Integration

task identified → fleet-dispatch-gate → [dispatch to remote node] → fleet-post-verification

This gate fires BEFORE any remote dispatch. It pairs with fleet-post-verification which fires AFTER remote work claims completion.

What NOT to Do

• Do NOT dispatch to a node you have not checked — "it was online last time" is not verification.
• Do NOT dispatch conflicting work — two nodes editing the same files is a merge nightmare.
• Do NOT dispatch irreversible tasks remotely — if it cannot be undone, do it locally.
• Do NOT skip this gate for "simple" tasks — simple tasks to offline nodes still fail.