HARD-GATE — verify target node readiness and task safety before dispatching work to remote fleet nodes
Dispatching work to a remote node that is offline, busy, or conflicting is worse than not dispatching at all. This gate ensures every remote task dispatch is safe, appropriate, and reversible before it leaves this node.
<HARD-GATE> Do NOT dispatch tasks to remote nodes until this gate passes. A failed dispatch to an offline node wastes time. A conflicting dispatch to a busy node destroys work. </HARD-GATE>Invoke this skill when ANY of these signals are present:
| Signal | Examples |
|---|---|
| Task targeting another node | fleet-send, fleet-task, daemon dispatch |
| Remote code execution | Asking another node to run commands, edit files, deploy |
| Multi-node coordination | Work that requires sequencing across 2+ nodes |
| Delegation of implementation | Sending a plan or subtask to a remote Claude session |
If even ONE signal is present, this gate fires.
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:
fleet-wake) and re-checkIf 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.
Not all work belongs on a remote node. Evaluate:
| Appropriate for Remote | NOT Appropriate for Remote |
|---|---|
| Independent subtasks with clear scope | Tasks requiring access to local-only resources |
| Work in the remote node's project focus | Tasks needing real-time back-and-forth with Aaron |
| Parallelizable implementation work | Security-sensitive operations (secrets, auth) |
| Testing/verification of remote systems | Tasks that modify shared state (Redis, git main) |
If the task requires local resources or shared state: GATE FAILS. Execute locally.
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:
If conflict detected: GATE FAILS. Options:
Every remote dispatch must have a rollback path. Remote failures are harder to diagnose and recover from than local ones.
| Reversibility | Examples | Gate Decision |
|---|---|---|
| Easy | New file creation, additive changes, branch work | PASS |
| Moderate | Config changes with backup, refactors with tests | PASS with caution |
| Hard | Destructive git ops, production deploys, schema migrations | FAIL unless emergency |
| Impossible | External API calls with side effects, data deletion | FAIL — execute locally with supervision |
If task is not reversible: GATE FAILS. Execute locally where you can monitor and intervene.
For urgent fleet operations (node is about to lose work, connectivity window closing):
fleet-watchdogfleet-post-verification immediately after completiontask 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.