Order vocabulary: minimal framework-owned set #2
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
The plan
The order vocabulary is the framework-owned contract between the layers: the Commander issues orders, the brain executes them, and later a decision model in either slot will issue them too. A new order type needs brain support, so the vocabulary cannot grow casually — it is settled here, in the framework, and it grows by addition only. A shipped order name is never removed or redefined.
Current state
addons/daisy/src/orders.gdcarries a PROVISIONAL starter set of seven constants —move_to,hold_position,patrol,investigate,target,retreat,reinforce— plusis_valid()andmake().DaisyCommander.issue_orderdrops any order whose type is not in the vocabulary, so the gate already exists; the set behind it is the draft. The design doc's order examples are "move there, target the player, run, interact with that" — noterunandinteractare NOT in the provisional set yet, andreinforcein the set is currently used as a Director objective that translates intomove_to, not as a direct order.What changes
Settle the minimal order set the brain understands, and define each order's payload schema. The work, in order:
run,interact): add or deliberately defer with a reason recorded here. The set should be as small as possible while covering the Commander and Director issues' needs — anything speculative stays out until a layer actually needs it.move_to {position},patrol {waypoints},investigate {position, radius},target {target_id},interact {target_id},retreat {position}or{away_from}. The brain reads only the fields its order type defines; unknown fields are ignored.orders.gdto the settled set — constants,ALL, and a doc comment per order type stating its fields. The growth-by-addition rule goes in the file header as the standing rule.issue_orderand reaches the brain; an unknown type is dropped and the brain's current order is untouched. The smoke test keeps passing.What done looks like
orders.gdmatches the settled set exactly, each type documented with its payload, the design doc's vocabulary section updated to match, and a test proving acceptance of every type and rejection of unknown types. After this lands, the small-brain issue can build execution against a stable contract, and the model-integration issue can validate model orders against it.Open questions
rundistinct fromretreat, or the same order with a parameter (flee a threat vs withdraw to a position)?interactbelong in the minimal set, or is it a later extension once an interaction exists to execute?reinforcean order at all, or only a Director objective that translates intomove_to— should it leave the order vocabulary?