Current state
work_order_create already has a conditions parameter in its zod schema (z.array(z.unknown()), src/tools/workOrder.ts:124-127), but it's a placeholder: mcp_workOrder.lua:156-161 unconditionally blocks any non-empty conditions array with "order prerequisite conditions are not supported in v1; specify material / item_type directly". This was a deliberate, documented v1 scope cut (the tool description says so outright).
work_order_list already reports a condition count per order (conditions = #o.item_conditions + #o.order_conditions, mcp_workOrder.lua:74) — so an order carrying conditions (created in-game, or via DFHack's own orders import) correctly shows e.g. "conditions": 2, but there's no way to see what those conditions are, create new ones, or edit existing ones.
What's missing
DFHack manager orders carry two condition vectors — confirmed directly from this project's own Lua (o.item_conditions, o.order_conditions) — that back the in-game manager screen's "Conditions" tab:
order_conditions — stock-threshold triggers: "only run this order while stock of X is below/above N." This is the condition type most DF players actually rely on for standing automation (e.g. "keep smelting ore only while bar stock < 10," "only make more bins while stock < 5") and is the highest-value target here.item_conditions — per-reagent constraints on the job's specific input items (material/quality/trait filters finer-grained than the single top-level material/item_type the tool already supports), tied to a specific reaction reagent index. Structurally more involved — a reasonable second phase.
Coupling with work_order_cancel's undo
work_order_cancel's recreate/undo handle is already explicit that it can't reproduce a conditioned order: faithful = (workshop_id == -1) and (nconds == 0) and (item_subtype == -1) (mcp_workOrder.lua:268) — cancelling a conditioned order today correctly reports not_reproduced for its conditions. If work_order_create gains the ability to build conditions, this recreate logic must be extended to actually encode them into the recreate spec too — otherwise the tool would be able to set conditions but never faithfully undo-and-restore them, which is a worse asymmetry than today's clean "not supported, told you so."
Backing / feasibility
DFHack's own orders command proves conditions are a well-understood, already-serializable concept: it exports/imports manager orders (including their conditions) as JSON under dfhack-config/orders/, with a library of example order files on the DFHack repo (e.g. basic.json) that model real condition JSON in practice — a good reference for designing the wire shape here, alongside the item_conditions/order_conditions struct fields the Lua already touches.
Proposed shape (execute-never-decide preserved)
work_order_list: report condition detail, not just a count. Read-only expansion, no gate needed — surface each existing order's order_conditions/item_conditions as structured facts (comparator, threshold amount, target material/item token, reagent index for item conditions) instead of the opaque conditions: N count.work_order_create: accept order_conditions first (the stock-threshold case) as structured input — comparator + amount + target material/item token — building the real struct field instead of being rejected. item_conditions (per-reagent) can follow once reagent-index addressing is worked out.work_order_cancel: extend the recreate spec to encode conditions once create can build them, so the undo handle stays faithful for conditioned orders instead of falling further behind.
As always: the agent supplies the exact condition (comparator, threshold, target) and the tool builds exactly that — no "you should add a stock condition" logic anywhere in the stack.
Effort / priority
M/L — touches all three work-order tools (list read side, create build side, cancel's undo side) plus a new struct area (manager_order_condition_order/_item). This is filling in an already-shipped v1 tool's explicitly-deferred scope rather than a new capability, so I'd rank it P1.
Current state
work_order_createalready has aconditionsparameter in its zod schema (z.array(z.unknown()),src/tools/workOrder.ts:124-127), but it's a placeholder:mcp_workOrder.lua:156-161unconditionally blocks any non-emptyconditionsarray with"order prerequisite conditions are not supported in v1; specify material / item_type directly". This was a deliberate, documented v1 scope cut (the tool description says so outright).work_order_listalready reports a condition count per order (conditions = #o.item_conditions + #o.order_conditions,mcp_workOrder.lua:74) — so an order carrying conditions (created in-game, or via DFHack's ownorders import) correctly shows e.g."conditions": 2, but there's no way to see what those conditions are, create new ones, or edit existing ones.What's missing
DFHack manager orders carry two condition vectors — confirmed directly from this project's own Lua (
o.item_conditions,o.order_conditions) — that back the in-game manager screen's "Conditions" tab:order_conditions— stock-threshold triggers: "only run this order while stock of X is below/above N." This is the condition type most DF players actually rely on for standing automation (e.g. "keep smelting ore only while bar stock < 10," "only make more bins while stock < 5") and is the highest-value target here.item_conditions— per-reagent constraints on the job's specific input items (material/quality/trait filters finer-grained than the single top-levelmaterial/item_typethe tool already supports), tied to a specific reaction reagent index. Structurally more involved — a reasonable second phase.Coupling with
work_order_cancel's undowork_order_cancel's recreate/undo handle is already explicit that it can't reproduce a conditioned order:faithful = (workshop_id == -1) and (nconds == 0) and (item_subtype == -1)(mcp_workOrder.lua:268) — cancelling a conditioned order today correctly reportsnot_reproducedfor its conditions. Ifwork_order_creategains the ability to build conditions, this recreate logic must be extended to actually encode them into the recreate spec too — otherwise the tool would be able to set conditions but never faithfully undo-and-restore them, which is a worse asymmetry than today's clean "not supported, told you so."Backing / feasibility
DFHack's own
orderscommand proves conditions are a well-understood, already-serializable concept: it exports/imports manager orders (including their conditions) as JSON underdfhack-config/orders/, with a library of example order files on the DFHack repo (e.g.basic.json) that model real condition JSON in practice — a good reference for designing the wire shape here, alongside theitem_conditions/order_conditionsstruct fields the Lua already touches.Proposed shape (execute-never-decide preserved)
work_order_list: report condition detail, not just a count. Read-only expansion, no gate needed — surface each existing order'sorder_conditions/item_conditionsas structured facts (comparator, threshold amount, target material/item token, reagent index for item conditions) instead of the opaqueconditions: Ncount.work_order_create: acceptorder_conditionsfirst (the stock-threshold case) as structured input — comparator + amount + target material/item token — building the real struct field instead of being rejected.item_conditions(per-reagent) can follow once reagent-index addressing is worked out.work_order_cancel: extend the recreate spec to encode conditions once create can build them, so the undo handle stays faithful for conditioned orders instead of falling further behind.As always: the agent supplies the exact condition (comparator, threshold, target) and the tool builds exactly that — no "you should add a stock condition" logic anywhere in the stack.
Effort / priority
M/L — touches all three work-order tools (list read side, create build side, cancel's undo side) plus a new struct area (
manager_order_condition_order/_item). This is filling in an already-shipped v1 tool's explicitly-deferred scope rather than a new capability, so I'd rank it P1.