Design: decide, fire, apply: route inventory

How the list was found

Two mechanisms reach the mod API from client-lib code, and both were enumerated:

1. Catalog targets. rg -n 'horizon_client_lib::' crates/horizon-mod-vocab/src/hooks returns 22 target = "horizon_client_lib::…" attributes in 19 declaration files. The generator classifies them in crates/horizon-mod-api-gen/src/lib.rs:344 (free_function_source, prefix horizon_client_lib::) and resolves each target's native_<hook> in dispatch.rs:46 (emit).
2. The callback table. 19 of the 22 are installed through NativeClientHooks (crates/horizon-client/src/native_client_hooks.rs:9, installed at entry.rs:225); the other 3 call mod_api::dispatch_ themselves (crates/horizon-client/src/crafting/native_hooks.rs:14,40,56).

Two consequences a reviewer should keep in mind:

• Every client-lib target currently names its function explicitly. None is implied by the Game::native_<name> default, so the design's "targets without an explicit annotation" set is empty today. This was checked against catalog.rs:363,508 (the default is a Game method) and hook_targets.rs:41 (resolution only rewrites Game native-hook modules). Re-run rg -n 'default_target|entry\("target"\)' crates/horizon-mod-api-gen/src/catalog.rs and read hook_targets.rs as well as the explicit-target and callback-table searches; searching explicit annotations alone does not establish the implicit set.
• None of the 22 receives a Host. 20 take &LoopContext and the two data-load collections (ingredient, recipe_property_sets) take &LoadContext. LoopContext is documented as holding "no game, world handle or mutable registry access" (crates/horizon-world/src/native_load_context.rs:189). The mutating ones instead write &mut out-parameters. That is the Host-less shape the clean break replaces.

Client-lib target inventory

Shape is the current dispatch shape; Treatment is this inventory's recommendation.

Counts: 22 targets, 19 files. 8 are the design's excluded motion values, is_ladder is a ninth motion-module target the design does not list (see Open items), 8 are mutating gameplay moments that need a typed decision, and 6 (including is_ladder) are pure queries/collections that need only a read-only fire boundary.

Menu routes

The read sets and bold outcome names below are migration proposals, not existing token validation. Existing callbacks mutate state directly; cancellation does not currently imply transaction rollback.

Paths are relative to the repository root. hooks/ is crates/horizon-mod-vocab/src/hooks/ and client/ is crates/horizon-client/src/. The design's line numbers moved; these are current.

• item_stacked_on_other (local pickup)

  Current owner

  client/menu.rs:3396 Menu::pickup, fires at :3418; event record client/menu/models.rs:28

  Vanilla method mirrored

  AbstractContainerMenu.doClick, PICKUP branch

  Read set

  player uuid and entity id, slot index, backing container and its index, primary button, cursor stack, clicked slot stack, the slot's may_place/may_pickup/allow_modification, live writes through SlotView

  Existing public result per outcome

  cancel skips the bundle override, and a cancelled handled (the event's cancellation result) also skips the plain pickup; uncancelled, the bundle answer decides and an unhandled click takes the ordinary pickup; click returns Ok(()) either way (menu.rs:3422) = Canceled/Applied; nothing reaches InvalidInput

• item_stacked_on_other (authoritative)

  Current owner

  client/lan/menu.rs:909 pickup, fires at :955; slot view lan/menu.rs:557

  Vanilla method mirrored

  same, server side

  Read set

  same, plus the guest's carried stack and the menu's registry id

  Existing public result per outcome

  same cancel/handled split (lan/menu.rs:959), then the guest resync (lan_crafting.rs:380)

• menu_slot_rules (local)

  Current owner

  client/menu.rs:1874 slot_rules (fires :1885); top-up loop menu.rs:2565 move_to (fires :2592)

  Vanilla method mirrored

  Slot.mayPlace, Slot.getMaxStackSize (not a pickup-permission hook)

  Read set

  menu registry id, backing slot index, stack id and components and count, the slot's own vanilla answer, the item maximum, container limits (menu.rs:1897)

  Existing public result per outcome

  refusal → may_place false: the carried stack is not placed, but the click itself can still apply, because a slot stack that matches the carried stack is taken onto the cursor anyway (pickup_inner, menu.rs:3487); so a placement refusal is Canceled only for the placement, not for the whole click, and click returns Ok(()) either way; clamp to 1..=99 (menu.rs:637, CONTAINER_MAX at :428) is Applied

• menu_slot_rules (LAN)

  Current owner

  client/lan/menu.rs:470 slot_rules (fires :493)

  Vanilla method mirrored

  same

  Read set

  same, resolved against the backing container or player inventory (lan/menu.rs:486)

  Existing public result per outcome

  placement refusal and bounded capacity answer as above; override applied at lan/menu.rs:506

• local click, cursor, throw, swap

  Current owner

  client/menu.rs:3204 click; :3396 pickup, :3433 pickup_inner, :3510 swap, :3683 pickup_all

  Vanilla method mirrored

  AbstractContainerMenu.clicked → doClick

  Read set

  slot count, cursor, every touched slot stack, input mode and button, quick-craft state

  Existing public result per outcome

  Err(OUT_OF_BOUNDS) = "IndexOutOfBoundsException" (menu.rs:659) → InvalidInput; Ok(()) → Applied or Canceled

• local quick move

  Current owner

  client/menu.rs:2645 quick_move; landing set :1837 quick_move_landing

  Vanilla method mirrored

  AbstractContainerMenu.quickMoveStack (abstract; menus override) and moveItemStackTo

  Read set

  source stack, destination ranges and roles, per-destination capacity via slot_max, registry id

  Existing public result per outcome

  no error path: no movement returns None; successful movement normally returns the original clicked stack (menu.rs:3180), with remainder stored back in the source; individual refused destinations are skipped

• local drag / quick craft

  Current owner

  client/menu.rs:3626 quick_craft_accepts, :3642 quick_craft_preview, drag branch of click at :3213

  Vanilla method mirrored

  doClick, QUICK_CRAFT stages 0/1/2

  Read set

  drag status, drag type, dragged slot list, cursor, per-slot may_place and maximum

  Existing public result per outcome

  preview is read-only and cannot commit; the commit is the ordinary click branch (InvalidInput/Applied as above)

• local pick-all

  Current owner

  client/menu.rs:3589 quick_move_all, :3600 quick_move_all_each, :3579 can_take_for_pick_all

  Vanilla method mirrored

  AbstractContainerMenu.canTakeItemForPickAll

  Read set

  target slot rules and the cursor stack

  Existing public result per outcome

  refused slots are skipped silently (Canceled), no error

• LAN authoritative clicks and backing storage

  Current owner

  client/lan/menu.rs:813 click; :909 pickup, :729 quick_move, :1125 swap, :1225 pickup_all, :1283 quick_craft; storage Slots::read :280 / write :306, still_valid :236

  Vanilla method mirrored

  AbstractContainerMenu.clicked/doClick on the server, reached through handleContainerClick

  Read set

  guest uuid and carried stack, authoritative menu generation and window id, menu registry id, backing container identity (still_valid), per-slot read/write through Slots

  Existing public result per outcome

  lan_inventory_click (lan_crafting.rs:327) answers through inventory_clicked (lan/containers.rs:746) and answer_click (:782): a stale state id sends the whole menu; otherwise mismatched or unclaimed changed slots and the cursor are corrected. This reconciles prediction after the click, rather than refusing a frozen action; no error packet, and Busy has no surface today

• recipe-book placement

  Current owner

  client/game/network/lan_crafting.rs:637 lan_place_recipe, :866 lan_check_recipe, :919 lan_apply_recipe; fires hooks/player_recipe_book_click.rs:13 at :671

  Vanilla method mirrored

  ServerPlaceRecipe.placeRecipe (the menu overload, which returns RecipeBookMenu.PostPlaceAction)

  Read set

  recipe id resolved from the display index, its placement, guest craft grid, every source slot, use_max, creative, known recipes

  Existing public result per outcome

  unknown or impossible recipe and unknown placement drop the packet (:662); a ghost plan is answered explicitly (:677), the existing counterpart of PostPlaceAction.GHOST → refused/no-change

• mod crafting placement

  Current owner

  client/game/network/lan_crafting.rs:1104 lan_mod_craft_apply, :989 lan_crafting_click

  Vanilla method mirrored

  ServerPlaceRecipe.placeRecipe over a mod menu

  Read set

  mod menu registry id, linked container slots, recipe placement, input slots

  Existing public result per outcome

  None when the menu is gone → refused; the click itself still returns handled

• recipe transfer

  Current owner

  client/game/network/lan_crafting.rs:759 guest_recipe_transfer, :802 guest_recipe_check

  Vanilla method mirrored

  ServerPlaceRecipe.placeRecipe (client-initiated placement)

  Read set

  recipe id, all source slots, destinations, all

  Existing public result per outcome

  TransferError::Unavailable and the other transfer results are encoded in the reply (:785) → refused/no-change

• anvil prepare and take

  Current owner

  client/menu.rs:1389 anvil_created, :1395 anvil_update, :1407 anvil_updated, :2066 anvil_undo, :2080 anvil_cancel, :2091 anvil_take; ordered sequence client/game/network/lan_stations.rs:172–:254; hooks hooks/anvil_craft_pre.rs:13, hooks/anvil_craft_post.rs:11, hooks/anvil_update.rs:21

  Vanilla method mirrored

  AnvilMenu.createResult, AnvilMenu.onTake

  Read set

  slot 0, slot 1, rename text, cost data slot, only_renaming, repair_count, result slot, player levels and inventory, cursor, the anvil block state

  Existing public result per outcome

  Pre cancel → anvil_cancel(undo) restores result, inputs, cost, inventory and cursor (lan_stations.rs:190) while click returns Ok(()) = Canceled; Post is a notice; the update answer replaces output and cost, or cancels to no result

• grindstone prepare and take

  Current owner

  client/menu.rs:1418 grindstone_place, :1431 grindstone_placed, :1446 grindstone_taken; ordered sequence client/game/network/lan_stations.rs:205–:254; hooks hooks/grindstone_place.rs:18, hooks/grindstone_take.rs:19

  Vanilla method mirrored

  GrindstoneMenu.createResult; the take hook mirrors the result slot's take handling in that class

  Read set

  slot 0, slot 1, result slot, enchantments (experience), cursor

  Existing public result per outcome

  place cancel → result slot emptied (Canceled); take cancel → result taken with no experience, sound or input reset (menu.rs:1452)

• menu close and merchant settlement

  Current owner

  client/menu.rs:3865 merchant_close (MerchantMenu.removed); ordinary container notice client/game/modding/native_menus.rs:257,269, hooks/player_container_close.rs:21; separate mod-menu notice native_menus.rs:307, hooks/menu_closed.rs:12

  Vanilla method mirrored

  AbstractContainerMenu.removed, MerchantMenu.removed

  Read set

  cursor stack, payment slots 0 and 1, player inventory

  Existing public result per outcome

  no result shape: player_container_close follows ordinary container close; menu_closed is specifically for a mod-opened menu. merchant_close settles cursor and payments through place_back; see vanilla evidence below for the living/connected versus dead/disconnected distinction

• merchant state

  Current owner

  client/menu.rs:3723 merchant_update, :3766 merchant_take, :3794 merchant_select, :3831 merchant_fill; fires client/game/items/trading.rs:543, client/game/network/lan_trading.rs:458; hooks hooks/trade_select.rs:11, hooks/trade_with_villager.rs:28

  Vanilla method mirrored

  MerchantContainer.updateSellItem, MerchantResultSlot.onTake, MerchantMenu.tryMoveItems

  Read set

  offers, selection hint, payment slots, player inventory 3..39, result slot, future experience

  Existing public result per outcome

  listen and collect only, so no cancel surface; the collect answer is written back and stands

Two structural notes for stage 2:

• The local click path mutates in place (menu.rs:3204): there is no point where a decision could be validated after listeners and before the write.
• The LAN coordinators take the menu out of storage before dispatching, with different results for a recursive click. The crafting table (lan_crafting.rs:996–:1002) finds no menu and stops. The inventory menu (lan_crafting.rs:341–:345) is rebuilt empty with unwrap_or_else, so a recursive inventory click continues on a fresh menu. Neither answers an admission Busy.

The Game-only mod-menu click hooks are not additional client-lib targets: menu_clicked (native_hooks/base.rs:3368, fired at game/modding/native_menus.rs:306) and menu_quick_move (native_hooks/base.rs:1615, fired at game/modding/api_values.rs:2020) are Game hooks, not client-lib targets, and are migrated with the rest of the server menu path.

Baseline caller fixtures

crates/horizon-client/src/menu/dfa_tests.rs pins three stage-2 acceptance rows through today's public Menu::click / Menu::place_recipe callers, without installing listeners or adding runtime code:

• Cursor stone 3 into an empty chest slot: cursor empty, destination stone 3.
• Quick move stone 10 into matching stacks of 60 and 58: each reaches 64 (adds 4 and 6), source empty, other chest slots and cursor unchanged.
• Place the vanilla stone pressure plate recipe from two stone: inventory source empty, exactly two grid stacks of one stone, output one plate. Taking that output consumes the grid once; a second empty-result click produces no additional plate. Placement stages ingredients; the result take consumes them. These are distinct operations in vanilla.

These are Rust caller regressions with independent vanilla expectations, not a new Java/Rust parity harness or proof of dispatch counts, tokens, cancellation, stale refusal or rollback. The recipe fixture is ignored by default and asserts that resources were actually loaded when explicitly requested. Run on the build server with prepared resources at .local/horizon-client/26.3:

cargo test -p horizon-client-lib --lib dfa_baseline_ -- --include-ignored

The sources live under horizon-client, but client_lib.rs owns the menu module and its unit tests. The recipe test reads HORIZON_TEST_RESOURCES, or .local/horizon-client/26.3 in the checkout when that is unset, and fails rather than passing silently when neither has the prepared data.

Vanilla evidence

Each row is a method this page cites, queried with python tools/rea_vanilla.py method <class> <method> from the 26.3 client jar. For overloaded methods select each --overload-index. Inventory classes use net.minecraft.world.inventory; ServerPlaceRecipe uses net.minecraft.recipebook, the packet listener uses net.minecraft.server.network, and LivingEntity uses net.minecraft.world.entity. The supplied data was read from the sibling horizon-pp .local via a process-local lab.LOCAL override, with scratch HORIZON_HOME and JDK 25. No game files are included here. REA's Java output for moveItemStackTo contains contradictory branches despite its complete status; the matching/empty-slot branches were cross-checked with JDK javap -c -p on the same jar.

• AbstractContainerMenu.clicked

  What it does (in words)

  Runs doClick synchronously inside one try; an exception becomes a crash report carrying menu type, menu class, slot count, slot, button and input type.

  Result

  complete

• AbstractContainerMenu.doClick

  What it does (in words)

  The click itself: drag staging for QUICK_CRAFT, then PICKUP (placement and take rules, safe insert/take, onTake), QUICK_MOVE through quickMoveStack, SWAP, CLONE and THROW. Reads the cursor and the slots it touches.

  Result

  complete

• AbstractContainerMenu.quickMoveStack

  What it does (in words)

  Abstract: the base class declares it and each menu supplies its own routing, so there is no single vanilla algorithm to mirror.

  Result

  no body (abstract)

• AbstractContainerMenu.canTakeItemForPickAll

  What it does (in words)

  Default answer is true; menus that restrict pick-all override it.

  Result

  complete

• AbstractContainerMenu.moveItemStackTo

  What it does (in words)

  Moves a stack into a slot range: first fills stacks with the same item and components up to each slot's maximum, then empty slots that accept the item, walking forwards or backwards as asked; the empty-slot pass stops after the first insertion; reports whether anything moved.

  Result

  REA + bytecode cross-check

• AbstractContainerMenu.removed

  What it does (in words)

  Server players only: a non-empty carried stack is dropped or placed back in the inventory and the carried slot is then emptied.

  Result

  complete

• ServerGamePacketListenerImpl.handleContainerClick

  What it does (in words)

  Runs on the server thread, resets the action time, drops a click for another container id, resyncs spectators and dead players, drops clicks on an invalid menu, logs and drops an out-of-range slot, then calls clicked.

  Result

  complete

• Slot.mayPlace

  What it does (in words)

  Default answer is true; subclasses restrict placement.

  Result

  complete

• Slot.mayPickup

  What it does (in words)

  Default answer is true; subclasses restrict taking.

  Result

  complete

• Slot.getMaxStackSize

  What it does (in words)

  The no-argument default is the container maximum; the stack overload also caps it at the item's maximum.

  Result

  bytecode cross-check

• Slot.safeInsert

  What it does (in words)

  The single-argument overload delegates with the whole count; the bounded overload refuses placement when disallowed, otherwise splits into an empty slot or merges matching stacks within capacity, returning the remainder.

  Result

  both overloads complete

• ChestMenu.quickMoveStack

  What it does (in words)

  Player inventory sources route to the chest range forwards; chest sources route to player slots backwards. The source is emptied or updated, and success returns the original stack copy.

  Result

  complete

• ServerPlaceRecipe.moveItemToGrid

  What it does (in words)

  Removes the requested matching ingredient count from inventory into a grid slot (or grows its stack), returning the still-missing count; no matching source returns -1.

  Result

  complete

• ResultSlot.onTake

  What it does (in words)

  Removes one item from each occupied recipe cell and handles recipe remainders. Two stone cells therefore consume two stone on one result take.

  Result

  complete

• AnvilMenu.createResult

  What it does (in words)

  Builds the result from the two input slots and the rename text, computing repair, enchantment and naming cost, only_renaming and the material count; writes the result slot, sets the cost data slot and broadcasts; empties the result when the cost is 40 or more without infinite materials.

  Result

  complete

• AnvilMenu.onTake

  What it does (in words)

  Charges the levels, uses up the material or input, clears the cost, sends the rename text through the server text filter, clears the left input, then with a 12% chance damages or breaks the anvil, always playing the use sound.

  Result

  complete

• GrindstoneMenu.createResult

  What it does (in words)

  Writes the result computed from the two inputs into the result slot and broadcasts.

  Result

  complete

• MerchantContainer.updateSellItem

  What it does (in words)

  Uses the second payment as the first matching candidate when the first is empty (without swapping stored slots); with nothing to pay it clears the result and future experience, otherwise matches an offer against the payments (retrying with them swapped), writes the result and its experience unless the offer is out of stock, and tells the client whether a result exists.

  Result

  complete

• MerchantResultSlot.onTake

  What it does (in words)

  Check-take achievements first, then for the active offer takes the payment in either order, tells the merchant, awards the trade statistic, writes the shrunken payments back and adds the offer's experience to the villager.

  Result

  complete

• MerchantMenu.tryMoveItems

  What it does (in words)

  Ignores an out-of-range index, sends each payment stack back to inventory slots 3..39 and gives up if one does not fit, then fills the payment slots from the selected offer's costs once both are empty.

  Result

  complete

• MerchantMenu.removed

  What it does (in words)

  Calls the base removed first, clears the trading player, returns on the client. On the server, for a dead or disconnected player it drops the two payment stacks; for a living connected player it returns them to the inventory (placeItemBackInInventory).

  Result

  smali (Java body unavailable)

• ServerPlaceRecipe.placeRecipe

  What it does (in words)

  Two overloads. The menu overload first answers PostPlaceAction.NOTHING when the grid cannot be cleared and dropping is disallowed; otherwise it gathers inventory/grid contents and calls tryPlaceRecipe, returning its RecipeBookMenu.PostPlaceAction. The private one takes the recipe and the stacked contents and places after checking the grid stacks can still grow.

  Result

  both complete

• LivingEntity.onClimbable

  What it does (in words)

  Spectators and gliding entities inside glide-through blocks are refused; a block in the climbable tag, or a usable trapdoor over a ladder, is accepted and its position remembered; otherwise false.

  Result

  complete

The three baseline expected values follow the pickup/insert rules, chest routing plus stack top-up, and recipe placement plus result-taking above. The pressure plate's two-stone shape and single-item output were checked in the supplied 26.3 data/minecraft/recipe/stone_pressure_plate.json.

NeoForge

The issue names no NeoForge counterpart. The web reader could not access the 26.3 menu Javadoc or stacking event Javadoc during this review. Other listed counterparts were not independently verified. No assertion that all paths or versions return a particular HTTP status is made. No NeoForge source or patches were read. Every counterpart contract below remains unverified; no equivalence is claimed.

Review coverage

The explicit search still finds 22 targets in 19 files; callback fields and direct crafting dispatches account for all 22. Default-target construction and resolution introduce no implicit client-lib target. Spot-checks included all nine motion entry lines, both menu hook entries, both breathing entries, all three crafting entries, both player-name entries, the LAN read/write/validity owners and the close notification owners. Every vanilla evidence method was re-queried (overloads separately); the added Slot.getMaxStackSize evidence was checked directly in bytecode. Book links from SUMMARY and the design note resolve relative to their containing Markdown files.

Open items

1. Read sets and versions. No action decision epoch was identified in these routes. Network menu state ids already exist (client/lan/containers.rs:797), but serve prediction reconciliation, not complete ABA validation. set_container_limits (client/menu.rs:1897) is a setter, not a validation check; LAN Slots::still_valid (client/lan/menu.rs:236) checks backing storage and reach. Stage 2 must establish complete action mutation epochs; the read-set column above is the proposed starting set per route.
2. Reentrancy and close. menu_closed follows a mod-opened menu close (native_menus.rs:307); ordinary container close uses player_container_close (native_menus.rs:269) and no route has an admission Busy. The LAN paths take the menu out of storage, but only the crafting table (lan_crafting.rs:996) then stops a recursive click; the inventory path (:341) rebuilds an empty menu and continues, and the local path clicks in place. Each route's public refusal for Busy must be chosen before code: local click has only Ok(())/IndexOutOfBoundsException, LAN has the resync, recipe placement has the transfer result byte.
3. Budgets. There are none today; a quick move walks every destination slot (menu.rs:2565) and a recipe plan is unbounded. Limits must be measured from real plans, as the design says.
4. Clamp or reject. The 1..=99 slot clamp (menu.rs:637, CONTAINER_MAX menu.rs:428) and the anvil update's material-cost clamp (negative to zero, hooks/anvil_update.rs) are existing documented clamps to preserve; structural errors already surface as IndexOutOfBoundsException.
5. Complete route evidence. For the two menu dispatch targets, item_stacked_on_other has explicit cancellation, and its cancel has the bundle/handled split above. menu_slot_rules is a query. The ordered anvil/grindstone sequence is in game/network/lan_stations.rs, not in menu.rs, so the design's owner list understates it. The server entry into clicked is now checked (handleContainerClick); the individual station algorithms' downstream callers are not.
6. Host. No target takes a Host: 20 take &LoopContext (native_load_context.rs:189) and the two data-load collections take &LoadContext; is_ladder's declaration says so explicitly. Adding Host once, in the decide/fire step, avoids a second signature break later.
7. is_ladder. It is a ninth motion-module client-lib target but not one of the design's eight excluded value transforms. It is a per-block boolean query, so this inventory recommends a read-only fire, not a token; the design must say whether it joins the motion exclusion.
8. NeoForge. Until a public 26.3 page is reachable, no counterpart contract (cancel semantics, transaction boundary, thread) can be assigned to the menu or station hooks.