dispatchworker

Documentation

Overview

guard.go — front each dispatch worker with the kernel (`fak guard`), a Go port of the dogfood-guard family in tools/dispatch_worker.py.

A dispatch worker IS the highest-volume dev work on a fleet node, and the LIVE production path is this compiled binary (dos.toml `worker_launch_template = 'tools/.bin/dispatchworker --lane {lane}'`, preferred over the Python sibling). Before this file the Go path talked STRAIGHT to the provider API — the kernel adjudicated NONE of the concurrent dispatch fleet, even though the Python sibling had guarded-by-default since #... . That made "the dispatch fleet dogfoods fak guard" true only on a path nothing runs in production.

Fronting the worker with `fak guard` puts the SAME kernel `fak serve` runs in front of every tool call the worker proposes (deny by structure, repair malformed args, quarantine poisoned results) and records every verdict in a durable, hash-chained DECISION JOURNAL under the gitignored .dispatch-runs/guard-audit/ — so the fleet eats the product on the real workflow, WITH a witness. Default ON; opt out per node with FLEET_DOGFOOD_GUARD=0. resolveFakBin fails OPEN to an unwrapped worker on a host that has not built `fak`, so the default never breaks dispatch.

The pure functions mirror dispatch_worker.py 1:1 so the ported guard_test table is a parity witness; only the OS touches (process env, crypto/rand token) differ.

Command dispatchworker launches one DOS dispatch worker on a selected backend — the Go port of tools/dispatch_worker.py, compiled to a single binary so the supervisor (`dos loop --enact`, or the watchdog canary) spawns a worker WITHOUT a Python interpreter (and without the bare-`python` token that ENOENTs on a python3-only node — the #22 residual).

dispatchworker --lane <lane>            # launch one worker on the lane
dispatchworker --lane <lane> --dry-run  # print the argv instead of launching
dispatchworker --lane <lane> --json     # machine-readable payload

Backend precedence: --backend > FLEET_WORKER_BACKEND > claude.

worker.go — the backend-select + launch core of the DOS dispatch worker, a Go port of tools/dispatch_worker.py.

This is the indirection seam that lets a fleet run a MIXED worker fleet — some Claude workers, some opencode workers — behind one launcher. The supervisor (`dos loop --enact`, or the watchdog canary) spawns this; it picks the backend and execs the real worker (`claude -p` / `opencode run`). As a compiled binary it removes the Python interpreter the old `python tools/dispatch_worker.py` launch token spawned — and, being interpreter-free, it can't ENOENT on a python3-only node the way the bare `python` token did (the #22 residual).

The pure functions (resolveBackend / buildCommand / childEnv / normalizeTimeout) mirror the Python so the ported test table is a parity witness; only launch() touches the OS (it execs a compiled worker, which the request-path exec ban does not cover — this is off-path dispatch tooling under cmd/).