From DOS — the trust substrate for agent fleets
Run bounded, recurring `dos-replan` sweeps, optionally guarded by the workspace's release policy. Use when the planning queue needs unattended refresh for a fixed cadence rather than one manual sweep.
How this skill is triggered — by the user, by Claude, or both
Slash command
/dos-kernel:dos-replan-loopThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
> **The thin loop.** It is mostly sequencing: run `/dos-replan`, run an
The thin loop. It is mostly sequencing: run
/dos-replan, run an optional auto-commit/release contract, increment a counter, schedule the next wakeup, and stop at the iteration cap. The one thing it must get right generically is the release guard — it reads the workspace's trunk from config, not a hardcoded branch name. (This repo's trunk ismaster, notmain— exactly the kind of host fact the guard must read, not assume.)
--interval <seconds> (optional, default 600 — 10 minutes).--max-iterations <N> (optional, default 20).Set the iteration counter to 1. Record the pre-existing dirty state of the tree
(so the auto-commit guard can tell what this sweep changed). Invoke the
/dos-replan Skill.
/dos-replan finishes: the guarded release contractIf /dos-replan made garden-only writes, optionally commit + release them — but
only behind the guard. The guard reads the trunk from config, not a literal:
dos doctor --workspace . --json
There is no trunk field in the doctor report today (it is a host fact); resolve
it the generic way: git symbolic-ref --short refs/remotes/origin/HEAD (the
remote's default branch). Fail closed: if that cannot be resolved (no
origin/HEAD — common in fresh clones / CI checkouts), treat the trunk as
UNKNOWN and skip the release entirely (record the sweep only). Do NOT fall
back to "the current branch" — that would make the on-trunk check below trivially
true on any branch and let an auto-commit proceed off-trunk. Then the guard fires
only when ALL hold:
master here, main elsewhere;
never hardcode either).If the guard passes, commit the garden writes with a generic subject and (if the
host wants it) call /release. If any condition fails — including an UNKNOWN
trunk — skip the release and just record the sweep — do not push code, do not
commit off-trunk.
Increment the counter; if it is below --max-iterations, schedule the next
wakeup --interval seconds out; else stop.
Parse the counter from the prior iteration, run /dos-replan, and re-run Step 2
again. Stop when the counter reaches --max-iterations.
This loop's "am I producing a witnessed net gain, or just spinning?" ratchet
already exists as the kernel's REPLAN_STALLED stop (loop_decide / docs/258,
#506): K consecutive UNPRODUCTIVE /dos-replan sweeps — replans that refilled or
gardened nothing — stop the loop and surface, because a sweep that did costly
nothing twice will not on a third identical pass. That IS the docs/351 outer ratchet
for a planning loop: its net gain is gardening/refill (a different metric than the
dispatch loop's reconcile-VERIFIED ship-count), so it does NOT fold under the
improve keep-gate — REPLAN_STALLED is its shaped equivalent. Same doctrine
across the loop roster: a loop that is running but not improving stops and hands
the judgment back, rather than burning the cap (the dispatch loop names this
not-ratcheting; this loop names it REPLAN_STALLED).
master
trunk and a main trunk are both handled — the SKP Phase 4 litmus./release; it does not build artifacts or run a host's
bespoke promotion gate (those are host/dev tooling, outside this loop).One replan cycle. The loop re-runs
dos verifyover the portfolio each cadence, then letsdos gatedecide DRAIN-vs-continue by exit code — the typed verdict, never the prose. Read the rung (source) and the code, not the headline.
$ dos doctor --workspace . --json | python -c "import sys,json;d=json.load(sys.stdin);print(d['paths']['plans_glob'])"
docs/**/*-plan.md
The WCR on-ramp: the portfolio is whatever matches plans_glob — host fact, read from config, not assumed.
$ dos verify --workspace . docs/82_liveness-oracle-plan liveness --json
{"phase":"liveness","plan":"docs/82_liveness-oracle-plan","rung":"direct","sha":"80d4f30","shipped":true,"source":"grep-subject","summary":"80d4f30 liveness: exclude the BIRTH acquire from the ADVANCING event count"}
SHIPPED via the grep-subject rung (exit 0) — a commit SUBJECT carrying the phase token flips it green; read the rung, not the bare verdict.
$ dos verify --workspace . docs/99_runtime-validation-and-the-actuation-boundary halt --json
{"phase":"halt","plan":"docs/99_runtime-validation-and-the-actuation-boundary","shipped":false,"source":"none"}
NOT_SHIPPED via the none rung (exit 1) — git ancestry has not stamped it; this phase is still in flight.
$ dos gate dispositions.json ; echo "exit=$?"
exit=3
dos gate returns the typed exit code: 3 = DRAIN (LIVE=0, DRAIN=3, STALE-STAMP=4, BLOCKED=5, RACE=6). Exit 3 means stop taking new work and let the in-flight phases settle this cycle — continue (LIVE=0) otherwise.
$ dos arbitrate --workspace . --lane src
{"auto_picked":true,"free_clusters":[],"lane":"benchmark","lane_kind":"cluster","outcome":"acquire","pick_count":null,"reason":"auto-picked free cluster lane benchmark (requested src was refused: lane src would edit the orchestrator's own running code … (SELF_MODIFY) …).","tree":["benchmark/**"]}
You asked for src; the arbiter handed back benchmark (exit 0, outcome:acquire) — the admission conjunction refused the hint (here SELF_MODIFY; a lane contended by a live lease redirects the same way) and the kernel named the real reason rather than double-book or false-narrate. A free, admissible lane you name is granted directly.
main — resolve it; this repo's is master.npx claudepluginhub anthony-chaudhary/dos-kernel --plugin dos-kernelRun recurring `dos-dispatch` cycles, switching to `dos-replan` when the backlog drains and stopping on the kernel's loop verdict. Use for unattended dispatch->replan->dispatch work across disjoint lanes.
Re-enters long-running Plans.md execution with fresh context using /loop dynamic mode and ScheduleWakeup. Invokes harness-work per cycle. Useful for autonomous multi-cycle task execution with configurable pacing.
Orchestrates long-running task loops using /loop and ScheduleWakeup to re-enter with fresh context each cycle, invoking harness-work via Agent for autonomous batch execution.