NEEDS_CATEGORIES used to be [&"rest", &"eat", &"sleep"]. Decision iterates
needs providers before eligible work providers and picks the first one
that returns a non-null job. EatProvider/SleepProvider correctly gate on
hunger/sleep thresholds (return null when not hungry/tired), so they
yield to work when no need is pressing. But RestProvider always returns
a job — by design, it's the catch-all fallback ("stand here"). With
"rest" in NEEDS_CATEGORIES the loop preempted on RestProvider every
tick: pawns assigned 'Rest at (50, 50)' and never reached the
chop/mine/construction providers despite valid designations.
Fix: remove &"rest" from NEEDS_CATEGORIES. RestProvider falls into the
eligible bucket; its provider.priority=0 sorts it last in the eligible
sort (chop=5, mine/construction=5, etc, win the priority tiebreaker).
work_priorities doesn't include a "rest" key so priorities.get falls
through to NORMAL=3, keeping rest eligible for everyone (the UI matrix
deliberately omits rest per Pawn.work_priorities comment).
Verified MCP runtime: fresh boot, all 3 pawns picked 'Build stone wall
at (44, 28)' instead of 'Rest at (50, 50)'; advanced to next wall site
within 5 seconds.
Bug surfaced by first real playtest with painted designations — the
in-context audit caught it within ~5 min of inspection.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
megaproxy
07fb66608a