Picks the single next unit of work across the whole MyThingsLab fleet, for the one available worker.
"Which of N designed tools / open issues should be tackled next" is a
recurring decision. myorchestrator next replaces it with a live,
re-computable answer — prioritized deterministically wherever possible.
Deterministic pre-work, in order:
- List every repo under the
MyThingsLaborg. - Collect candidates: open issues carrying each repo's backlog label, plus
"scaffold this tool" candidates for designed-but-unbuilt tools (from the
canonical fleet registry,
tools_manifest.json, shipped asmythingspackage data in my-things-core; override with--manifest). - Keep only ready scaffolds — every
depends_onentry satisfied (a depended-on tool already built, or a core-contract addition landed). - Rank: strict oldest-first, boosted by live ledger urgency signals (an
unresolved
kind=drift/ akind=askawaiting a reply jumps the queue). - Only a genuine tie among top candidates (same age, same urgency) reaches the
one optional Engine call — "choose which the worker tackles next, and
why." Against
NoopEngineit falls back to strict oldest-first.
Its one side effect is updating a single pinned "next up" tracking issue via
gh issue edit, routed through Action → Policy. It decides; it never builds
and never chains into another tool's CLI.
myorchestrator next # human-readable
myorchestrator next --json # machine-readablemyorchestrator is never invoked directly by another tool's CLI — the org
root's fleet_dispatch.py imports Orchestrator as a
library to rank candidates and hand them to workers, and
fleet_cycle.py chains it with the rest of the fleet
(myplanner → fleet_dispatch → mytester/mychangelogger →
myprojector → myreporter → mytelegrambot) into one autonomous cycle. See
the org README for the full loop.
python -m venv .venv && source .venv/bin/activate
pip install -e ../my-things-core -e ".[dev]"
pytestMIT — see LICENSE.