prompt-gates-vs-engine-gates

Arithmetic goes in the engine; judgment goes in the prompt. If a rule can be checked with an integer comparison it's engine law; if it needs to understand a sentence, it's the adjudicator's call.

The dividing line

Every rule in hunker lives on one side of a seam:

rule	side	why
"you can't spend 5 wood when you have 2"	engine (_apply_one)	integer comparison against live stock
"a meter can't leave [0, cap]"	engine	arithmetic
"a repair pays its claimed materials"	engine	arithmetic
"fishing needs the stream"	prompt	requires understanding "I fish" from freeform text
"cooking needs the hearth; smelting needs the forge"	prompt	same — feasibility of intent
"nonsense gets a flat no, marginal gets high difficulty"	prompt	pure judgment

The engine cannot gate what it cannot parse: no validator can tell that "smoke the venison" is hearth-work. The adjudicator sees the true state (location, zone, station) and is instructed to refuse work done at the wrong place. The engine's contribution is truth, not enforcement — it puts the real station in the payload so the model judges against facts, not the player's claim.

The cost, stated honestly

A prompt gate is soft: a weak model can ignore it, and the engine will still apply whatever legal deltas come back. The hearth-and-forge slice accepted this deliberately (flagged as the load-bearing hotspot in its PR) because the alternative — an engine-side keyword gate on freeform text — reverses llm-proposes-engine-rolls and starts building exactly the brittle intent-parser the LLM exists to replace.

Prediction: prompt-gate violations scale with model weakness, so the fix for a leaky gate is a better model or a sharper prompt rule, never a regex. If a gate MUST be hard (safety, economy exploits), redesign the state so the violation becomes arithmetic — e.g. if wrong-station crafting ever breaks the game, make crafted goods a resource that only station verbs can mint, and the engine's stock check becomes the gate.