Grid & Flow is a Project Zomboid Lua mod, so the security model is mostly multiplayer abuse prevention rather than secrets protection. The goal is to make normal client actions defensible on a server: clients may request actions, but the server or final timed action must re-check that the request is still plausible.

This document is the working reference for Roadmap Phase 2: Flow Micro - Security Hardening.

• Security-sensitive world validation is isolated in GridAndFlow_Security.lua so server command handlers and timed actions use the same gates.
• Grid & Flow server commands are namespaced under GridAndFlow.
• Server commands sanitize coordinate and object-index payloads before object lookup.
• Pump, disassembly, repair, and placement commands require the player to be alive/capable and near the target square.
• Server interactions reject protected safehouse squares for players who are not allowed by the vanilla safehouse check, when that API is available.
• Pump, disassembly, and repair commands verify the target object type before mutating, repairing, or removing world objects.
• Pump activation requires valid power at the pump square.
• Pump activation requires a linked building service, completed building-line priming, remaining building reserve, and no other active pump for that same service.
• Pump filter service commands revalidate player distance, target pump type, screwdriver ownership, required filter housing/cartridge items, and current filter state before installing, replacing, or removing filter state.
• Pump and industrial-generator placement are server-authoritative in multiplayer: clients send placement requests, and the server creates the world object only after final validation.
• The old Flow Micro pipe network has been removed from active runtime/scripts/assets and archived only in ignored local reference material.
• Grid & Flow world objects now carry provenance fields (gfModId, gfObjectKind, gfObjectSchemaVersion, gfServerAuthoritative) and are registered in server ModData when created by Grid & Flow.
• Server-side object predicates reject spoofed Grid & Flow flags unless the object matches the server registry.
• Server-side object-added auditing removes untrusted Grid & Flow flagged objects instead of letting them become usable pumps or industrial generators.
• Disassembly re-checks the required wrench server-side before removing the object or returning an item.
• Repair re-checks object damage, required wrench, and required material server-side before increasing object health or consuming material.
• Grid & Flow server commands have a small per-player cooldown to reduce spam-triggered recalculations.
• Pump placement revalidates the pump item, wrench, target square, nearby building service target, and player distance before the timed action creates the object.
• Local Flow Micro water consumption through vanilla fixtures uses a Grid & Flow server command that revalidates player distance, vanilla fixture object type, linked building service, active powered pump, and requested water amount before reducing reserve state.
• Loot injection checks for target procedural tables before modifying them.
• Grid & Flow avoids broad monkey-patching of vanilla water, power, context menu, or build systems.
• During full-development builds, Grid & Flow runtime modules fail closed outside Project Zomboid debug mode before registering menus, commands, actions, loot injection, pump maintenance, UI, build cursors, or network logic.
• Macro facility assessment uses a server-authoritative command that validates facility id, control-panel square, player distance, and panel power before rolling selected components.
• Facility component repair, industrial generator connection, and facility startup use server-authoritative commands with facility id, anchor/component square, distance, power/readiness, object type, and tool/material validation.
• Facility calibration is a separate server-authoritative step before startup; it revalidates panel power, player distance, operational power, completed repairs, and diagnostic tool ownership.
• Industrial generator world objects are namespaced with Grid & Flow modData and can be removed or repaired through the same validated disassembly/repair paths used by Flow Micro objects.
• Industrial generator placement at facility anchors is server-authoritative in multiplayer and revalidates facility id, anchor index, square, required item, wrench, distance, and existing facility generator state.
• Industrial generator refueling revalidates facility id, generator anchor, player distance, the trusted placed generator object, and a usable petrol item server-side before fuel state changes.
• Macro service-zone state is internal mod state for now; it does not patch vanilla electricity or water queries and cannot grant broad world power/water effects yet.
• Industrial generator fuel consumption for macro facilities is server-side and only runs for already-online facilities that are powered by an industrial generator.
• Facility debug/admin commands require the debug runtime gate and server admin/owner/moderator access on multiplayer before reset, force-online/offline, admin repair/refuel/reroll/start/stop, facility/service-zone/coordinate state print, usage-counter print/reset, or performance-counter print/reset actions run.
• Facility event logs store only capped facility-level event names/details, not player names, SteamIDs, IPs, chat, inventory, or exact player paths.
• Security logging is controlled by GridAndFlow.Config.securityLogEnabled so development/server owners can suppress rejected-command logs if needed.
• docs/COMMAND_AUDIT.md now tracks the expected validation checklist and regression payloads for every client-exposed command.

• Remote pump toggles from forged coordinates.
• Remote pump toggles through spoofed Grid & Flow object flags.
• Stale object-index commands after the world object changed.
• Malformed client payloads that could previously reach numeric comparisons.
• Pump activation requests after the local power state changed.
• Client-authoritative Grid & Flow pump or industrial-generator creation in normal multiplayer flows.
• Client-created Grid & Flow flagged world objects that are not registered by the server.
• Remote or stale disassembly requests after the player moved away, dropped the required wrench, or targeted the wrong object.
• Remote or stale repair requests after the player moved away, dropped repair requirements, targeted the wrong object, or selected an undamaged object.
• Remote or stale industrial-generator refuel requests after the player moved away, lacked fuel, targeted the wrong anchor, or had no trusted generator object on the square.
• Normal-path pump placement after dropping the pump item or required wrench.
• Basic command spam against Grid & Flow server commands.

• Project Zomboid still owns the low-level replication model for placed world objects. A fully malicious client or compromised server environment can attack engine-level paths outside this mod's Lua command handlers.
• The server-side untrusted-object audit is intended to remove Grid & Flow flagged objects that arrive through low-level replication without a Grid & Flow server registry entry. It does not claim to police unrelated vanilla or third-party mod objects.
• Active Flow Micro water use now happens through vanilla building fixtures backed by Grid & Flow building-service reserve state while the linked pump is powered, active, and non-empty.
• Legacy Grid & Flow water outlets are not part of active runtime/scripts/assets and should not become supplied by pumps.
• Build 41 does not provide a formal automated security test harness for mod Lua. Multiplayer security validation remains partly manual.
• Project Zomboid loads static script and texture-pack data before Grid & Flow Lua modules can check debug mode, so the debug-only gate disables runtime behavior but cannot prevent static item/recipe definitions from being parsed.
• Future public-service adapters, actual zone-power switching, public-water restoration, and vanilla sink/power integration must receive the same command-surface review before release.
• GridAndFlow_VanillaAdapters.lua is intentionally disabled by default. The water adapter can write WaterShutModifier only after explicit config enablement: Build 41 derives the decision from all grid service zones being online, while Build 42 derives it from physical water-plant zone state. The electricity adapter still no-ops until validated.
• Facility coordinates and component anchors are development placeholders until validated in-game; do not treat them as final security boundaries for public multiplayer release.

• Validate args is a table.
• Normalize all coordinates and indexes through shared helpers.
• Look up the object from the server world, not from client-provided object state.
• Check player distance and vertical distance.
• Check player capability and protected safehouse/square access when applicable.
• Check target object type or facility id.
• For placed objects, require server-side provenance/registry checks before trusting Grid & Flow modData flags.
• Re-check tools, parts, power, fuel, skill, and facility state server-side when relevant.
• Rate-limit commands that can trigger recalculation, expensive scans, sounds, or state replication.
• Fail closed: invalid requests should return without changing world state.
• Document the change in CHANGELOG.md and update multiplayer validation notes.