Server Authority Migration Map

Server Authority Migration Map

This page is the design map for moving A2 Wasp Warfare from trusted client affordances toward server-owned gameplay authority.

Scope: Chernarus source mission first, Arma 2 Operation Arrowhead 1.64 behavior only, then LoadoutManager propagation. All source paths below are relative to Missions/[55-2hc]warfarev2_073v48co.chernarus/ unless noted.

Use this with Hardening roadmap, Networking and public variables, Economy, towns and supply, Commander/HQ lifecycle, Upgrades and research atlas, Feature status, Testing workflow and agent-test-plan.schema.json.

Page ownership: this page owns the design model for authority migrations: principles, flow table, handler checklist, "do not migrate casually" notes and validation expectations. Hardening roadmap owns canonical patch order and branch sequencing. Focused playbooks own detailed implementation shape.

Why This Exists

Many high-impact findings are not isolated bugs. They are the same ownership problem repeated across different mission systems:

• client UI validates affordability, role or range;
• client or payload chooses side, target, class, position, amount or reward;
• server executes a legitimate handler with limited recomputation;
• BattlEye filters in the repo do not provide a shipped fallback authority layer; see External integrations for the canonical shipped-posture evidence.

Do not patch seven spend/effect paths in seven unrelated styles. Pick an authority model first, then migrate flows in a consistent order.

Authority Principles

Principle	Rule for future patches
Client UI is affordance	Menus may show prices, buttons and hints, but the server owns final acceptance, debit and effect.
Server recomputes truth	Recompute side, role, funds, supply, cost, upgrade state, object validity, range and placement from server-held state.
Harden dispatch before payloads	Current stable has the PVF namespace lookup/CODE guard; finish explicit registered-handler membership before deeper per-handler rewrites.
Direct PV channels are separate	ATTACK_WAVE_INIT, side supply temps, supply mission PVs and marker/state PVs bypass the generic PVF dispatcher.
Arma 2 OA sender identity is weak	A publicVariable event handler does not hand the server a clean sender identity. If a handler needs authority, include a requester/player/team object where safe and cross-check group, side, ownership and UID when available.
Keep old UI until confirmation	Let the client request work and show feedback, but do not mutate final funds/effects until the server accepts or rejects.
Log compactly	Use small INFORMATION logs for accepted high-value transactions and WARNING logs for rejected malformed or unauthorized requests. Avoid hot-loop spam.
BattlEye is defense in depth	Public server filters can reduce attack surface, but they are not the mission's source of authority. Canonical shipped-filter evidence lives in External integrations.

Patch Order Routing

Canonical patch sequencing lives in Hardening roadmap. Use this page when designing or reviewing a specific authority migration, then return to the roadmap or machine backlog to claim work.

Need	Open
Prioritized patch order	Hardening roadmap
Machine-readable work packages	agent-hardening-backlog.jsonl
Generic PVF dispatcher patch	PVF dispatch implementation
ICBM/Nuke RequestSpecial patch	ICBM authority
Direct attack-wave channel patch	Attack-wave authority
Economy first cut	Economy authority first cut
Upgrade request authority	Upgrades and research atlas
Town/camp capture reward authority	Towns/camps/capture atlas
Commander vote/reassignment semantics	Commander vote/reassignment
Commander/HQ repair and recovery authority	Commander/HQ lifecycle
Supply truck/heli authority cleanup	Supply mission authority cleanup

Registered Server PVF Handler Authority Matrix

This table is the post-dispatch work queue. On current origin/master@f8a76de34, the same commit as origin/claude/b74.1-aicom@f8a76de34, the generic PVF dispatcher has stopped compiling arbitrary sender-provided handler strings and now uses missionNamespace getVariable plus CODE guards; it still needs explicit registered-handler allowlists/logging. These registered commands also need their own payload, requester and authority checks because a valid command name can still carry forged state.

Registration source on current stable/B74.1: Common/Init/Init_PublicVariables.sqf:9-28 registers 20 server-bound commands, while :60-63 compiles each SRVFNC* handler and adds value-only WFBE_PVF_<Command> server PVEHs.

2026-06-04 recheck: a focused mini-scout verified that the "thin" handlers are not just theoretical entries in the registry. Active client/source callers still send RequestVehicleLock from MHQ locking (Client/Action/Action_ToggleMHQLock.sqf:15) and spec-ops unlocking (Client/Module/Skill/Skill_SpecOps.sqf:52), RequestTeamUpdate from the commander menu (Client/GUI/GUI_Menu_Command.sqf:428), RequestUpgrade from the upgrade menu (Client/GUI/GUI_UpgradeMenu.sqf:161), RequestAutoWallConstructinChange from CoIn (Client/Module/CoIn/coin_interface.sqf:217), and RequestChangeScore from town/camp/supply/upgrade reward paths (Client/PVFunctions/TownCaptured.sqf:71,79; Client/PVFunctions/CampCaptured.sqf:38; Client/Module/supplyMission/supplyMissionCompletedMessage.sqf:22; Client/Functions/Client_FNC_Special.sqf:118). Treat these as live effect handlers, not dead registry leftovers.

Patch boundary: the PVF dispatcher namespace lookup is now source-present on current stable, but the registered-handler allowlist/logging part remains open. Even after that final dispatcher guard, it will not validate score values, vehicle objects, team arrays, side scalars, upgrade ids or delegation UID/FPS payloads inside legitimate handlers.

Root-scope warning: the Chernarus source mission is the hardening baseline, but modded fork trees still carry live RequestSpecial and PVF helper surfaces. A 2026-06-04 scout rechecked Modded_Missions and found RequestSpecial sends in Eden/Lingor/Napf tactical, economy, UAV, nuke, repair-camp, teamleader, group-query and HC delegation paths, plus registered RequestSpecial entries in their Common/Init/Init_PublicVariables.sqf. Fixing one root is not a global hardening claim unless the owner chooses and validates a modded propagation/maintenance policy.

2026-06-23 DR-55 current-B74.1 refresh: current docs/source HEAD@925d56e01a1e is unchanged from a0721301d4f5 for checked PVF init/dispatcher paths and still registers value-only PVEHs at Common/Init/Init_PublicVariables.sqf:46,51, dispatching through Server_HandlePVF.sqf:14 / Client_HandlePVF.sqf:22 Call Compile; Miksuu b8389e748243 and origin/perf/quick-wins@0076040f match that old dispatcher shape in checked maintained roots. Current stable origin/master@f8a76de34 equals origin/claude/b74.1-aicom@f8a76de34; it still registers value-only PVEHs at Init_PublicVariables.sqf:56,61 and uses missionNamespace getVariable + CODE guards at server Server_HandlePVF.sqf:14-15 and client Client_HandlePVF.sqf:32-33. Current B69 origin/claude/b69@8d465fce and adjacent B74 origin/claude/b74-aicom-spend@b23f557f match that generic PVF boundary; the checked B69..B74 and B74..B74.1 generic PVF dispatcher/init deltas are empty. No allowlist/sender/requester symbol was found in checked current-stable/B69/B74 dispatcher/init files. BIKI's addPublicVariableEventHandler page documents the callback value as event data; Wasp currently discards even the variable-name part before the server handler layer, so DR-55 remains a separate requester-context migration from the handler-name allowlist patch.

Handler	Current server behavior	Authority status	First validation rule
RequestVehicleLock	Applies _vehicle lock _locked, then broadcasts SetVehicleLock (RequestVehicleLock.sqf:6-8).	Payload-authoritative object effect.	Validate requester, side, ownership/role, lockable class and range before changing lock state.
RequestOnUnitKilled	Re-derives some kill context, trashes bodies, updates statistics, awards score/bounty and may call RequestChangeScore (RequestOnUnitKilled.sqf:51-92).	Partly server-derived but event-payload sensitive.	Re-derive killed side from object state where possible, reject stale/null/duplicate kill reports and set a killed-object idempotency flag before award paths.
RequestChangeScore	Replaces the target unit's score by removing old score and adding _newScore, then broadcasts ChangeScore (RequestChangeScore.sqf:7-13).	High-risk direct score overwrite.	Replace caller-stamped absolute score with server-owned award reasons/deltas; never accept arbitrary target/new-score payload from clients.
RequestCommanderVote	Starts side vote when side logic wfbe_votetime <= 0, using payload side/name (RequestCommanderVote.sqf:14-22).	Payload-side workflow trigger.	Validate requester belongs to the side, derive name from requester, and rate-limit or ignore duplicate vote starts. Keep this trigger hardening separate from DR-47 vote-resolution semantics in Server_VoteForCommander.sqf:24-29,43; use Commander vote/reassignment for the vote matrix.
RequestNewCommander	Sets side logic wfbe_commander, spawns commander assignment and broadcasts new-commander-assigned (RequestNewCommander.sqf:12-14).	High-impact commander mutation.	Accept only from the server vote/assignment path or validate requester authority, side, candidate team membership and vote state. Keep call-shape/notification/UI identity smoke tied to Commander vote/reassignment.
RequestStructure	Looks up side structure names, announces building start for major classes and executes Construction_<script>.sqf with payload class/side/pos/dir (RequestStructure.sqf:8-21).	DR-6 construction authority gap.	Validate requester commander/repair-truck role, side, funds, class allowlist, HQ/base area, placement and debit before ExecVM.
RequestDefense	Finds payload defense class in side defense names and calls ConstructDefense with payload side/pos/dir/manned flag (RequestDefense.sqf:2-10).	DR-6 defense authority gap.	Validate requester, funds, class allowlist, manned-defense permission, position/range and debit before construction.
RequestJoin	Checks UID team history, launch side and optional AntiStack DB/team skill before sending join-answer; stores side on accept (RequestJoin.sqf:18-89).	Real server-side gate, with object/UID shape assumptions.	Preserve this as a server-owned pattern; add null/UID/object shape guards and keep team-swap protection independent from AntiStack DB availability.
RequestMHQRepair	Forwards side-only payload to MHQRepair (RequestMHQRepair.sqf:1).	HQ repair/recovery authority gap.	Include requester and repair/recovery context; server validates dead HQ, side, vehicle/range/class, repair count, funds and one-time WASP recovery flags, then takes a server-side repair mutex before creating a replacement HQ.
RequestSpecial	Spawns HandleSpecial, which multiplexes group, support, UAV, ICBM, HC, town delegation, camp repair, AICOM/patrol bookkeeping and other tags (RequestSpecial.sqf:1; current B74.1 Server_HandleSpecial.sqf:5-520).	Broad mixed-risk router; ICBM is P0.	Split by tag. Harden "ICBM" first; then validate support fees/upgrades/cooldowns, HC identity, town-delegation vehicle ownership, camp repair side/object state, AICOM/patrol bookkeeping payloads and HQ-kill payload shape.
RequestTeamUpdate	Applies behavior/combat/formation/speed to a payload group array or all teams on a payload side (RequestTeamUpdate.sqf:9-25).	Commander/team-control payload mutation.	Validate requester is commander or authorized leader for the requested groups/side; allowlist behavior/combat/formation/speed values.
RequestUpgrade	Raw-spawns WFBE_SE_FNC_ProcessUpgrade with side/id/level payload (RequestUpgrade.sqf:5).	DR-23 upgrade authority gap.	Validate commander/team, side, current level, requested next level, dependencies, cost and funds before spawning the upgrade worker.
RequestAutoWallConstructinChange	Sets global isAutoWallConstructingEnabled from payload and replies to payload player (RequestAutoWallConstructinChange.sqf:3-7).	Low/medium CoIn workflow toggle.	Validate requester/player object and side/commander/build context before changing the global toggle; keep response targeted.

RequestSpecial Tag Triage

Do not patch RequestSpecial as one giant rewrite. It is a tag router with materially different authority needs:

Tag family	Current behavior	First hardening gate
Bookkeeping: update-teamleader, group-query, upgrade-sync, update-clientfps, track-playerobject	Mutates teamleader, group join, upgrade sync flags, HC/client FPS records or player-object lists from payloads (current B74.1 Server_HandleSpecial.sqf:6-41,77-93,469-480). Depth scout 2026-06-04 confirmed group-query trusts payload _group, _player and _side; when the target leader is AI and the group lacks wfbe_uid, it calls Common_ChangeUnitGroup.sqf:3-11 and moves the payload player into that group (Server_HandleSpecial.sqf:13-31).	Shape-check objects/UIDs/groups and ensure the requester can speak for the team/player record; for group-query, derive the requester/player relationship and side server-side before any group move.
Support effects: Paratroops, ParaVehi, ParaAmmo, uav, RespawnST, repair-camp	Older checked roots let client tactical/UAV paths own fee, upgrade and cooldown checks locally (GUI_Menu_Tactical.sqf:262-276,371-373,513-527; Client/Module/UAV/uav.sqf:27-52) while the server spawns support scripts, kills supply trucks or recreates camp bunkers from payload side/position/team/object state. PR #125 177ef1385f binds these maintained Chernarus/Takistan surfaces to server-side requester/team/player/actor/funds/cooldown/object validation and adds static smoke for player support/UAV, supply-truck respawn and camp repair. Runtime proof is still pending, and older/modded roots remain open.	Preserve the PR #125 requester/server-owned model; collect accept/reject runtime proof for exercised support paths. Remaining work stays in residual RequestSpecial tags, modded propagation and sender-auth architecture.
Delegation/HC: update-town-delegation, connected-hc	Registers HC groups and appends delegated vehicles to town active-vehicle state (current B74.1 Server_HandleSpecial.sqf:96-124,427-463).	Validate HC identity/owner and ensure delegated vehicle lists belong to the expected town/HC handoff.
HQ/endgame-sensitive: process-killed-hq	Forwards payload killed event into WFBE_SE_FNC_OnHQKilled (current B74.1 Server_HandleSpecial.sqf:144-145).	Validate killed object is the side HQ/MHQ being tracked and reject duplicate killed-event processing.
P0 special weapon: ICBM	Trusts side/base/target/team payload, waits for target death and spawns NukeDammage (current B74.1 Server_HandleSpecial.sqf:127-135).	Use ICBM authority before any other RequestSpecial hardening claim.

Migration Table

Flow	Client entrypoint	Current server/current handler	Current trust	Target authority owner	Patch shape	First validation
PVF dispatch	Any WFBE_CO_FNC_SendToServer, SendToClient or SendToClients command	Current stable/B74.1/B69/B74 Server_HandlePVF.sqf:14-15, Client_HandlePVF.sqf:32-33, registry in Init_PublicVariables.sqf:55-61; docs/source, Miksuu/perf/historical refs still need the old Call Compile replacement.	Current stable/B74.1/B69/B74 dispatchers use missionNamespace getVariable _script and spawn only resolved CODE, but they do not prove the name is one of the registered SRVFNC* / CLTFNC* handlers and do not log rejected names.	Registered handler lookup.	Add explicit allowlists exported from Init_PublicVariables.sqf, reject non-registered or non-CODE names with a compact warning log, and keep Spawn until scheduled handler needs are audited.	Valid RequestJoin or RequestVehicleLock, valid LocalizeMessage or HandleSpecial, bogus handler rejected and logged once.
PVF sender authentication (DR-55)	Any client-to-server WFBE_PVF_* request or direct authority PV	Current stable origin/master@f8a76de34 / origin/claude/b74.1-aicom@f8a76de34, current B69 8d465fce and adjacent B74 b23f557f forward only (_this select 1) into WFBE_SE_FNC_HandlePVF at Init_PublicVariables.sqf:56,61; Server_HandlePVF.sqf:11-15 resolves/spawns the chosen handler with only handler parameters. Docs/source HEAD@925d56e01a1e is unchanged from a0721301d4f5 for checked PVF paths and still has value-only registration plus old Call Compile dispatchers; Miksuu b8389e748243 and perf 0076040f match that old shape. The checked B69..B74 and B74..B74.1 generic PVF dispatcher/init deltas are empty, and no allowlist/sender/requester symbol was found in checked current-stable/B69/B74 dispatcher/init files.	The effect handler sees payload data but not an authenticated publisher identity, so legitimate handler names can still carry forged side/team/object/funds fields.	Server requester/context authority.	Carry authenticated requester context to server handlers (owner/UID/player object, cross-checked against the PVEH origin or a server-owned session table), then re-derive side, commander/team role, funds and object ownership inside each handler. Keep this separate from the handler-name allowlist patch.	From a non-owning/enemy client, forged RequestVehicleLock, RequestChangeScore, RequestTeamUpdate, RequestSpecial, attack-wave detail and supply-completion payloads reject; valid owner/commander/support flows still work.
ICBM / nuke	Client/Module/Nuke/nukeincoming.sqf:23	Server/PVFunctions/RequestSpecial.sqf:1, "ICBM" in current B74.1 Server_HandleSpecial.sqf:127-135	Client supplies side, base/target object, cruise object and team; server later spawns NukeDammage.	Server special-weapons authority.	Use ICBM authority: validate commander/team, side, module/upgrade state, funds/cost and impact anchor server-side; server owns debit and launch acceptance.	Valid commander launch still works; forged non-commander, wrong-side, dead/invalid target and invalid base do not spawn NukeDammage.
Construction and defenses	Client/Module/CoIn/coin_interface.sqf	Server/PVFunctions/RequestStructure.sqf:3-20, RequestDefense.sqf:2-8	DR-6 owns exact payload-trust proof; construction atlas owns the runtime map.	Server base-construction authority.	Include requester context, validate side and commander/repair-truck authority, funds, HQ/base area, placement, class allowlist and manned-defense permission; server debit before build.	Accepted HQ/factory/defense builds still work; wrong-side, unaffordable, out-of-base and disallowed manned-defense requests reject.
Player factory buy	Client/GUI/GUI_Menu_BuyUnits.sqf:102-156	No registered RequestBuyUnit; Client/Functions/Client_BuildUnit.sqf:217,249,411-450 creates units/vehicles locally	Client checks funds, spawns BuildUnit, debits with ChangePlayerFunds, and creates units/vehicles locally.	Large redesign: server buy authority, or explicit public-server dependency on BattlEye script filters while locality is preserved.	Prefer a server-validated buy request for high-value purchases. If preserving client locality temporarily, document it as not server-authoritative and harden with BE scripts.txt outside mission code.	Buy infantry and vehicles on hosted/dedicated; forged createVehicle/createUnit path must be constrained by chosen authority model or BE posture.
Upgrades	Client/GUI/GUI_UpgradeMenu.sqf and upgrade menu send path	Server/PVFunctions/RequestUpgrade.sqf:5, Server_ProcessUpgrade.sqf:12-18,40-44,85-87	Raw payload selects side, upgrade id and level; server processes timing and state but cost/dependency authority is client-side.	Server upgrade authority.	Use Upgrades and research atlas: server validates commander/team, side, current level, requested next level, dependencies, cost and funds/supply; server owns debit and state transition.	Valid upgrade completes; invalid id/level, skipped dependency, insufficient funds and wrong-side/role reject.
Town/camp capture rewards	Client/PVFunctions/TownCaptured.sqf:37-81, Client/PVFunctions/CampCaptured.sqf:19-40	Server-owned capture state in Server/FSM/server_town.sqf:226-241 and server_town_camp.sqf:122-138	Server owns town/camp side transitions, but client PV handlers award funds locally and request score after the capture broadcast.	Server reward authority.	Keep ownership/capture server-owned; move bounty eligibility, distance/participation, commander bonus and score/funds mutation to server-side reward handling or explicitly constrain with public-server policy.	Valid nearby capture still pays once; distant, replayed, wrong-side or forged reward attempts do not change funds/score.
Side supply	Common ChangeSideSupply callers	Current target origin/claude/build84-cmdcon36@6f2fc4bd10c8339fd13be087d327717ff58c85e8 Chernarus plus maintained Vanilla: Common_ChangeSideSupply.sqf:8-14,24-26, Server_ChangeSideSupply.sqf:1-64	Common side still broadcasts a signed temp amount, but current target now floors negative results to 0, caps at max supply, validates payload type/count, side type, side-vs-channel, amount type and wires west/resistance/east handlers in both maintained roots. Remaining trust gap: the temp handler does not receive a trusted requester or re-derive whether the requested spend/reward delta is authorized.	Server side-supply ledger.	Do not reopen DR-22 clamp/shape on current target. Next patch should add requester/server-owned acceptance per flow, restrict supply mutation callers, and preserve the current floor/side-channel checks.	Positive reward still applies; overspend cannot increase supply; west/east/resistance side mismatch rejects; forged requester/unauthorized spend attempts reject once the ledger/requester patch exists.
Supply missions	Client/Module/supplyMission/supplyMissionStart.sqf:20-39	supplyMissionStarted.sqf:1-65, supplyMissionCompleted.sqf:2-34	Client stamps SupplyFromTown and SupplyAmount on vehicle; completion reads those vars and rewards side supply.	Server logistics authority.	Server re-derives source town/reward from trusted state where possible, standardizes cooldown casing, avoids duplicate loops/handlers, and narrows broad object scans.	Truck mission complete/repeat/JIP cooldown; forged reward/source ignored; PR #1 destruction reward pays once.
Attack waves	Docs/source Client/FSM/updateclient.sqf:240; current stable/B74.1/B69/B74/B74.2 Client/FSM/updateclient.sqf:260; Common/Functions/Common_AttackWaveActivate.sqf:3-8	Server_AttackWave.sqf:1-38, Server/PVFunctions/AttackWave.sqf:1-62	Docs/source HEAD@426de4570993, current stable/B74.1 origin/master@f8a76de34 / origin/claude/b74.1-aicom@f8a76de34, current B74.2 origin/claude/b74.2-aicom@21b62b04, current B69 8d465fce and adjacent B74 b23f557f all keep ATTACK_WAVE_INIT = [_supply, _side]; server uses payload _supply to compute discount/duration and ATTACK_WAVE_DETAILS also trusts _side, _priceModifier and _attackLength (Server_AttackWave.sqf:5-6,15,23,27,36,38; AttackWave.sqf:19,23-25,40). B74.2 source-Chernarus line drift is buy-menu/constants only (GUI_Menu_BuyUnits.sqf:105,250-251,422; Init_CommonConstants.sqf:604); maintained Vanilla stays stable-shaped. Scoped origin/master..origin/claude/b74.2-aicom touches only source-Chernarus GUI_Menu_BuyUnits.sqf and Init_CommonConstants.sqf among checked attack-wave paths, and scoped d472da6a..21b62b04 is empty.	Server support-mode authority.	Treat direct PVs as request/detail surfaces; server re-derives side supply, validates requester side/permission, deducts intended cost and clamps modifier/duration before starting wave, then protects the detail handler from forged payloads.	Legit wave starts; forged exaggerated supply/detail payload cannot change modifier, duration, side or cost; wrong-side requests reject; late-join attack-wave state remains documented.
Gear, EASA and service	GUI_BuyGearMenu.sqf:421-441, GUI_Menu_EASA.sqf:40-49, GUI_Menu_Service.sqf:126-230	Mostly no server handler; support scripts run from client service menu	Gear/EASA/service affordability and effects are client-local. Service rearm/refuel debit unconditionally when action selected.	Server equipment/service ledger or explicit local-only trust decision.	Add server request/acceptance for public-server hardening. As a small correctness patch only, use Service menu affordability guards for local price/funds/context parity.	Gear buy, EASA equip, service repair/rearm/refuel/heal; unaffordable and wrong-context requests reject or are BE-constrained.
Structure sale	Client/GUI/GUI_Menu_Economy.sqf	No server sale PVF found in current docs/findings	Client commander check, refund and destruction are local.	Server economy/base authority.	Add sale request with server commander, ownership, object type, refund and destruction validation; server owns refund/effect.	Valid sale works once; wrong-side/non-commander/stale object sale rejects.
Normal MHQ repair	Client/Action/Action_RepairMHQ.sqf:5-35	Server/PVFunctions/RequestMHQRepair.sqf:1, Server_MHQRepair.sqf:7-79	Client checks dead HQ/range/repair count/funds, debits locally and sends only side; server creates repaired MHQ from side state and only sets wfbe_hq_repairing after entering the worker.	Server HQ repair authority.	Include requester and repair-vehicle context; server validates dead HQ, vehicle range/class, side, repair count and funds, takes a server-side in-flight repair mutex, then debits and creates the MHQ.	Valid repair works; wrong-side, alive-HQ, far-vehicle, exhausted-count and insufficient-funds requests reject; two rapid repair requests produce one accepted repair.
WASP HQ recovery	WASP/actions/Action_RepairMHQDepot.sqf:8-28	RequestMHQRepair server path plus client-side cashrepaired and town supply reset	Client checks/debits cash, sends side-only repair request, sets public flags, moves HQ wreck and resets town supplyvalue; its duplicate guard is also client-local.	Server HQ recovery authority.	Include requester context; server validates dead HQ, commander/side, one-time flag, funds, recovery/drop position and town-SV side effects before repair, sharing the same server-side repair mutex as normal repair.	Valid recovery works once; wrong-side, insufficient-funds and second repair reject; town supply reset is server-owned; concurrent normal/cash repair attempts cannot create two HQs.

Handler Validation Checklist

Use this checklist for every authority-sensitive handler before writing code:

Check	Ask
Requester	Which player, unit or group is asking? Can the server verify that object is alive, local enough to inspect, and belongs to the claimed side?
Role	Must the requester be commander, driver, repair-truck user, team leader, support user or side member?
Side	Is side derived from server-known group/player/object state instead of a payload scalar/string?
Funds/supply	Does the server recompute price, balance and resulting floor/cap?
Object validity	Are object refs non-null, alive where required, the expected class, and not stale from a previous action?
Locality	Does the effect need to run on server, client owner, headless client or all clients?
Position/range	Is the target/base/source within valid distance and terrain/build constraints?
Class allowlist	Is the requested class/name in the side's server-held allowlist?
Upgrade/dependency	Does the requested level match current state and dependencies?
Idempotency	Can duplicate PVs, duplicate event handlers, JIP replays or retries apply the effect twice?
State broadcast	Does accepted server state need object variables, side logic vars, marker replay or pull-based JIP sync?
Logging	Is there one compact accepted/rejected log at the transition point?
BattlEye	Does production need a matching filter update as defense in depth?
Test record	Is a future or actual test entry compatible with agent-test-plan.schema.json?

Do Not Migrate Casually Yet

Area	Why
Client-local player factory buys	Moving createUnit/createVehicle authority can change locality, queue ownership, AI group ownership and buyer disconnect behavior. Design the request/acceptance model first.
Gear/EASA/service	Many UI/effect paths mutate inventory, weapons, magazines, fuel, damage and vehicle state locally. Quick local guards are not a full authority migration.
Modded missions	Napf, Eden and Lingor are divergent forks; other modded folders are stubs. Source fixes do not automatically make all modded missions safe.
Autonomous AI logistics	Supply truck/heli AI work sits on partially disabled/missing logistics code. Finish the owner decision before reviving autonomous behavior.
BattlEye posture	Filters usually live outside the mission PBO. Confirm production BEpath before claiming public-server hardening; use External integrations for in-repo evidence.

Interim Live-Server Posture

Until server authority is implemented, do not describe the repo as public-server hardened.

Minimum interim posture:

1. Harden PVF dispatch lookup first.
2. Add production BattlEye publicVariable and scripts filters for the highest-risk request/effect paths.
3. Treat RequestSpecial "ICBM", construction/defense, upgrades, side supply, player buys, structure sale, supply rewards, attack waves, gear/EASA/service and WASP HQ recovery as a single trust-boundary class.
4. Record which flows are still client-authoritative in Feature status.
5. For every patch, record validation level in Testing workflow terms.

Validation Tie-In

Every server-authority patch should produce a test record or planned test record shaped like agent-test-plan.schema.json.

Recommended minimum coverage by phase:

Phase	Minimum evidence
PVF foundation	source-only registry check plus hosted or dedicated PV smoke.
ICBM and attack waves	dedicated-smoke; live-server-sensitive if BattlEye or production config changes.
Economy ledger	dedicated-smoke for each migrated flow; hosted/listen smoke if locality changes.
Supply and support systems	dedicated-smoke, jip-smoke for cooldown/state, PR #1 vehicle reuse/destruction tests when relevant.
HC/AI-adjacent migrations	hc-smoke if group ownership, delegation or AI spawning changes.

Machine Notes

Agents should read this page before claiming any agent-hardening-backlog.jsonl item with network-authority, economy, gameplay-security, support-systems or BattlEye categories. For BattlEye-specific shipped evidence, start with External integrations.

This page does not change mission behavior. It is the source-backed design layer for future implementation branches such as hardening/pvf-dispatch, hardening/icbm-authority, hardening/economy-ledger, hardening/supply-missions and hardening/attack-wave-authority. For the order in which those branches should be claimed, use Hardening roadmap.

Dedicated playbook: ICBM authority expands the DR-27 row into an implementation-ready patch shape for RequestSpecial "ICBM", NukeIncoming, Server_HandleSpecial.sqf and NukeDammage.

Dedicated playbook: Attack-wave authority expands the DR-41 row into an implementation-ready patch shape, including the current all-side-supply spend model.

First implementation cut: Economy authority first cut sequences the broad economy class into side-supply clamp, upgrade authority, construction/defense authority and deferred player-buy redesign.

Dedicated atlas: Upgrades and research expands the upgrade row into the live menu, side config, server worker, AI commander worker, stale legacy dialog and server-authority migration shape.

Continue Reading

Previous: Hardening roadmap | Next: ICBM authority playbook

Main map: Home | Fast path: Quickstart | Agent file: agent-context.json