@dsalazardev/ai-hub-cli 0.0.0-stage → 0.2.0

package/skills/shared/gamedev-multiplayer/evals/cases.yaml

@@ -0,0 +1,44 @@
+skill: gamedev-multiplayer
+
+should_trigger:
+  - prompt: "I have a single-player platformer in Godot 4 and I want to add online co-op. How do I sync the two players' positions and let one host the game?"
+    why: "Adding multiplayer/sync to a game is the core trigger; should produce ENetMultiplayerPeer host/join + MultiplayerSynchronizer/authority guidance."
+  - prompt: "In my Unity shooter the client sets its own health with a NetworkVariable and players can cheat. How should authority actually work?"
+    why: "Server-authoritative / never-trust-the-client + NetworkVariable write permissions; center of gravity of this skill."
+  - prompt: "Players rubber-band and teleport around when there's lag in my online game. What's the right way to fix the jitter?"
+    why: "Symptom text for prediction/reconciliation + snapshot interpolation; routes here without the word 'netcode'."
+  - prompt: "Should I use a dedicated server or peer-to-peer for my PvP game, and how do I stop clients from cheating?"
+    why: "Topology + authority decision, the second core section; not an infra/hosting question about how to run the server."
+  - prompt: "In Unreal, how do I replicate a health value to all clients and run a RepNotify when it changes, and what's the difference between a Server RPC and a NetMulticast?"
+    why: "Unreal Actor replication mapping: ReplicatedUsing/DOREPLIFETIME + Server vs NetMulticast RPC semantics."
+  - prompt: "What tick rate should my authoritative server run at, and how do I test multiplayer locally with fake latency before I ship?"
+    why: "Tick/netrate + local multiplayer testing with simulated latency, both explicitly owned here."
+  - prompt: "Is ServerRpc/ClientRpc still the way to do RPCs in Unity Netcode for GameObjects, or is there a newer attribute?"
+    why: "Version-contract question the skill answers directly: unified [Rpc(SendTo.X)] preferred, legacy pair still supported, UNet removed."
+
+should_not_trigger:
+  - prompt: "How do I read gamepad input and make my character jump in Godot 4?"
+    route_to: "godot"
+    why: "Single-player input/gameplay is the engine skill's job; no network dimension."
+  - prompt: "Set up a matchmaking backend and auto-scale dedicated game servers on a cloud provider with a lobby database."
+    route_to: "deployment"
+    why: "Server hosting/matchmaking/orchestration infra is delegated to deployment; this skill designs the in-game net layer, not the fleet."
+  - prompt: "My character controller clips through walls at high speed and collisions feel inconsistent — how do I fix the physics?"
+    route_to: "gamedev-physics"
+    why: "Collision/character-controller/determinism is physics; netcode consumes determinism but doesn't own the physics fix."
+  - prompt: "Build a realtime chat app with presence indicators over WebSockets for my website."
+    route_to: "webhooks"
+    why: "Generic web realtime that is not a game world/simulation is not this skill's domain."
+  - prompt: "Do a general threat model and authz review of my app's permission boundaries."
+    route_to: "secure-coding"
+    why: "Language/domain-agnostic threat modeling is secure-coding; this skill keeps only game-specific anti-cheat controls."
+
+capability:
+  - scenario: "In Godot 4.x, wire a server-authoritative 'fire weapon' from a client so the server validates and applies the shot, with the same code working on a listen-server host. Show the RPC and the authority handling."
+    must_include:
+      - "Uses ENetMultiplayerPeer (create_server / create_client) assigned to multiplayer.multiplayer_peer — NOT the removed NetworkedMultiplayerENet"
+      - "Declares the intent RPC with @rpc(\"any_peer\", ...) so a client may call it, and the client sends it with rpc_id(1, ...) to the server"
+      - "Gates the body with multiplayer.is_server() (or is_multiplayer_authority) so authoritative logic runs once, correctly on a listen host"
+      - "Identifies the sender with multiplayer.get_remote_sender_id() and validates before applying (server decides the result, client sends intent only)"
+      - "Uses no Godot 3.x APIs (no master/puppet/remote keywords, no rset, no rpc_config as a legacy call)"
+      - "Distinguishes replicating authoritative state (e.g. via MultiplayerSynchronizer / a replicated var) from firing the one-shot RPC event"

package/skills/shared/gamedev-multiplayer/references/godot-high-level-multiplayer.md

@@ -0,0 +1,133 @@
+# Godot 4.x high-level multiplayer
+
+The high-level API sits on top of `MultiplayerPeer` and gives you three moving parts: **transport**
+(`ENetMultiplayerPeer`), **events** (`@rpc`), and **state** (`MultiplayerSynchronizer` +
+`MultiplayerSpawner`). Authority is per-node, set with `set_multiplayer_authority()`.
+
+Everything here is Godot 4.x. Godot 3.x used `master`/`puppet`/`remote`/`remotesync` keywords, `rset`,
+and `NetworkedMultiplayerENet` — **all gone**; never emit them.
+
+## Transport & connection
+
+```gdscript
+const PORT := 9999
+const MAX_PLAYERS := 8
+
+func host() -> void:
+    var peer := ENetMultiplayerPeer.new()
+    var err := peer.create_server(PORT, MAX_PLAYERS)
+    if err != OK: push_error("host failed: %s" % err); return
+    multiplayer.multiplayer_peer = peer
+
+func join(ip := "127.0.0.1") -> void:
+    var peer := ENetMultiplayerPeer.new()
+    peer.create_client(ip, PORT)
+    multiplayer.multiplayer_peer = peer
+
+func _ready() -> void:
+    multiplayer.peer_connected.connect(_on_peer_connected)     # server-side: a client joined
+    multiplayer.peer_disconnected.connect(_on_peer_disconnected)
+    multiplayer.connected_to_server.connect(_on_connected)     # client-side
+    multiplayer.server_disconnected.connect(_on_server_gone)
+```
+
+Useful `multiplayer` (SceneMultiplayer) members: `is_server()`, `get_unique_id()` (1 == server),
+`get_remote_sender_id()` (valid only inside an RPC body), `multiplayer_peer`.
+
+## RPCs — the `@rpc` annotation
+
+Params are optional and **order-free**. Signature: mode, sync, transfer mode, channel.
+
+- **mode**: `"authority"` (default — only the node's multiplayer authority may invoke it on remotes) or
+  `"any_peer"` (any client may invoke it — use this for client→server intent, then validate).
+- **sync**: `"call_remote"` (default) or `"call_local"` (also run on the caller).
+- **transfer**: `"unreliable"` (default), `"unreliable_ordered"`, or `"reliable"`.
+- **channel**: an int, and it must be the **last** argument.
+
+```gdscript
+# Client asks the server to fire. any_peer + call_local so the host's own call runs too.
+@rpc("any_peer", "call_local", "reliable")
+func request_fire(target: Vector3) -> void:
+    if not multiplayer.is_server(): return          # authority gate
+    var shooter := multiplayer.get_remote_sender_id()
+    if not _can_fire(shooter): return               # server-side cooldown / validation
+    _apply_shot(shooter, target)                    # server mutates authoritative state
+
+# Server → everyone, cosmetic only. Unreliable is fine for FX.
+@rpc("authority", "call_local", "unreliable")
+func play_muzzle_fx(at: Vector3) -> void:
+    _spawn_fx(at)
+
+# Invoking: rpc() = all peers; rpc_id(peer, ...) = one peer; rpc_id(1, ...) = the server.
+func _on_fire_pressed(target: Vector3) -> void:
+    rpc_id(1, "request_fire", target)               # client sends intent to server
+```
+
+Both sides must declare the **same** `@rpc` annotation on a function with the same name/path, or the call
+is rejected. A missing/mismatched annotation is the usual "my RPC does nothing" cause.
+
+## Authority
+
+```gdscript
+# On spawn, give the owning peer authority over its input node; server keeps authority over stats.
+func setup(owner_peer_id: int) -> void:
+    $Input.set_multiplayer_authority(owner_peer_id)      # recursive=true by default
+    # $Stats stays under server authority (peer id 1)
+
+func _physics_process(delta: float) -> void:
+    if $Input.is_multiplayer_authority():                # only the owner reads local input
+        var dir := Input.get_vector("left","right","up","down")
+        rpc_id(1, "submit_input", dir)                   # send intent to server
+```
+
+`set_multiplayer_authority(id, recursive := true)` sets it on the node (and children). Check with
+`is_multiplayer_authority()`; read with `get_multiplayer_authority()`. Authority drives who a
+`MultiplayerSynchronizer` streams *from* and who may call `"authority"`-mode RPCs.
+
+## State — MultiplayerSynchronizer
+
+Add a `MultiplayerSynchronizer` node, assign it a **replication config** (`SceneReplicationConfig`, edited
+in the inspector: list the properties to sync, e.g. `position`, `rotation`, and per-property spawn vs sync).
+It streams those properties **from the node's authority to the other peers** every replication interval.
+
+- `replication_interval` — how often synced properties are sent (throttle to save bandwidth).
+- `delta_interval` — for delta-synced properties.
+- Visibility: `set_visibility_for(peer_id, visible)`, `public_visibility`, `update_visibility()` — scope
+  who receives a given synchronizer (relevancy / anti-wallhack).
+
+Because it is authority-driven, an owner-authoritative synchronizer trusts the client's position — fine for
+co-op, risky for competitive. For server-authoritative movement, keep authority on the server and have the
+client send input via RPC (see prediction-and-latency.md).
+
+## Spawning — MultiplayerSpawner
+
+`MultiplayerSpawner` replicates *instancing*. Point its `spawn_path` at the parent node, register spawnable
+scenes with `add_spawnable_scene("res://player.tscn")`, and when the authority instances a child under that
+path (or you call `spawn(data)`), the same instance appears on every peer — including late joiners, which is
+the big win over manually RPC-ing spawns.
+
+```gdscript
+@onready var spawner := $MultiplayerSpawner
+
+func _ready() -> void:
+    spawner.spawn_function = _spawn_player     # optional custom factory
+
+func _on_peer_connected(id: int) -> void:      # server only
+    if multiplayer.is_server():
+        spawner.spawn(id)                      # data passed to spawn_function on every peer
+
+func _spawn_player(peer_id: int) -> Node:
+    var p := preload("res://player.tscn").instantiate()
+    p.name = str(peer_id)
+    p.setup(peer_id)
+    return p
+```
+
+## Gotchas
+
+- Server (peer 1) is also a client on a listen host — always gate authority logic behind `is_server()`.
+- `get_remote_sender_id()` is only meaningful *inside* an RPC; it returns 0 outside one.
+- Node paths must match across peers for RPCs/synchronizers to resolve — spawn via `MultiplayerSpawner` so
+  names line up, and set `name` deterministically (e.g. the peer id).
+- Reliable RPCs are ordered per channel and cost more; keep FX/heartbeats unreliable, keep state changes
+  reliable or (better) replicated.

package/skills/shared/gamedev-multiplayer/references/prediction-and-latency.md

@@ -0,0 +1,104 @@
+# Prediction, reconciliation & latency hiding
+
+The whole reason netcode is hard: the speed of light. A round trip (RTT) of 60–150 ms is normal, and if the
+owning client had to wait a full RTT to see its own movement, the game would feel broken. The techniques
+below keep it responsive **without** giving up server authority. This is engine-agnostic theory; the
+per-engine references show where the hooks live.
+
+## The authoritative loop (mental model)
+
+1. Client samples input each tick, tags it with a **sequence number**, sends it to the server, and **applies
+   it locally immediately** (prediction).
+2. Server receives inputs, simulates them on its fixed tick, and produces authoritative state. It stamps each
+   state snapshot with the last input sequence number it processed for that client.
+3. Client receives the authoritative snapshot, **reconciles**: snap to the server state, then re-apply every
+   input *after* the acknowledged sequence number (they haven't reached the server yet).
+4. Other (remote) entities are rendered from buffered snapshots, **interpolated** slightly in the past.
+
+Server is always the source of truth. The client only ever *guesses ahead* and gets corrected.
+
+## 1. Client-side prediction
+
+The owning client runs the same movement code the server will run, on the same fixed timestep, the instant it
+presses a key — no waiting. Requirements:
+
+- **Deterministic** movement/simulation for the predicted entity (same input + same state → same result).
+  This is why `gamedev-physics` determinism matters here.
+- A **ring buffer** of unacknowledged inputs (`{seq, dt, input}`), kept until the server acknowledges them.
+- Predict only what the client owns (its pawn). Never predict other players — interpolate them instead.
+
+## 2. Server reconciliation
+
+When an authoritative snapshot arrives tagged "processed up to input N":
+
+```
+clientState = serverState               # trust the server
+discard buffered inputs with seq <= N   # server already applied these
+for each remaining buffered input (seq > N):
+    clientState = simulate(clientState, input)   # replay the unacknowledged ones
+```
+
+If the replayed result matches what the client already had, the correction is invisible. If it diverges (the
+server disagreed — lag, a missed collision, a rejected move), the entity snaps: the visible **rubber-band**.
+Goal is to *minimize* divergence, not to suppress the correction — hiding a legitimate correction is how you
+get players walking through walls on their screen.
+
+- **Smoothing**: for small corrections, blend toward the corrected position over a few frames instead of
+  hard-snapping, so a 2 cm disagreement isn't a visible pop. Hard-snap large ones.
+
+## 3. Snapshot interpolation (remote entities)
+
+You receive remote entities' state only every send-tick (e.g. every 50 ms) — rendering the latest packet
+directly makes them teleport. Instead, keep a small buffer and render them ~1–2 snapshots **in the past**:
+
+- **Interpolation delay** ≈ 100 ms (2× send interval + jitter margin). Render remote entities at
+  `now − delay`, interpolating between the two snapshots that straddle that time.
+- Trade-off: everyone else is shown slightly in the past. That is fine and standard.
+- **Extrapolation** (dead reckoning) predicts a remote entity forward when a packet is late — cheaper on
+  bandwidth but wrong on direction changes; prefer interpolation and only extrapolate briefly to cover a gap.
+
+So on one client, three clocks coexist: **its own pawn** = present (predicted), **remote entities** = past
+(interpolated), **the server** = the arbiter reconciling the two.
+
+## 4. Lag compensation (server-side rewind)
+
+For instant/hitscan hits, the shooter aimed at where they *saw* the target — which is `interpolation delay +
+½ RTT` in the past. If the server tests the hit against the target's *present* position, the shooter misses
+despite a perfect aim. Fix: the server keeps a short **history** of every entity's recent positions and, when
+processing a shot, **rewinds** the world to the shooter's view time before testing the hit.
+
+- Store ~1 second of position history per entity (a ring of transforms per tick).
+- On a shot: reconstruct positions at `clientRenderTime`, run the trace, then restore.
+- Trade-off: the victim can be hit just after ducking behind cover ("shot behind the wall"). This is an
+  accepted fairness choice favoring the shooter; cap how far back you rewind to bound the unfairness.
+
+## 5. Tick rate, send rate, netrate
+
+- **Simulation tick** — fixed Hz the server steps the world (20 / 30 / 60+; higher = more precise + more CPU).
+- **Send rate / snapshot rate** — how often state goes on the wire; often lower than sim tick, and independent
+  of client render FPS. This is the "netrate/updaterate/cmdrate" family in shooters.
+- **Client render FPS** — decoupled from both; render via interpolation between fixed-step states.
+- Bandwidth ≈ replicated-bytes × send-rate × relevant-peers. Shrink it with relevancy/visibility scoping,
+  quantized/delta-compressed fields, and lower send rates for distant or unimportant actors.
+
+**Never run gameplay in a variable `_process`/`Update`/`Tick` on a networked game** — use a fixed timestep
+(`_physics_process`, `NetworkUpdate`/`FixedUpdate`, Unreal's fixed sim) so prediction and reconciliation
+replay identically on client and server.
+
+## Alternative model: deterministic lockstep / rollback
+
+For fighting games and some RTS: no per-frame state replication at all — every peer runs the identical
+deterministic simulation and only **inputs** are exchanged. **Lockstep** waits for all inputs before advancing
+(one slow peer stalls everyone). **Rollback** (GGPO-style) predicts absent inputs, then rolls back and
+re-simulates when the real inputs arrive — excellent feel, but demands *bit-perfect determinism* (watch
+floats, iteration order, RNG) and bounded state you can snapshot/restore cheaply. Choose it only when you can
+guarantee that determinism; otherwise the client-server model above is the safer default.
+
+## Checklist for a responsive authoritative game
+
+- [ ] Owning pawn predicted locally on a fixed timestep; inputs buffered with sequence numbers.
+- [ ] Server acks the last processed input seq in each snapshot; client replays unacknowledged inputs.
+- [ ] Small corrections smoothed, large ones snapped; corrections never fully suppressed.
+- [ ] Remote entities interpolated ~100 ms in the past from a snapshot buffer.
+- [ ] Hitscan uses server-side rewind bounded to ~1 s of history.
+- [ ] Sim tick / send rate / render FPS all decoupled; bandwidth scoped by relevancy.

package/skills/shared/gamedev-multiplayer/references/unity-and-unreal-netcode.md

@@ -0,0 +1,166 @@
+# Unity & Unreal netcode
+
+Per-engine deep dive for the two C#/C++ engines. Godot lives in its own reference.
+
+---
+
+## Unity — Netcode for GameObjects (NGO)
+
+NGO is Unity's first-party high-level netcode. **UNet / HLAPI is removed** — never emit `NetworkIdentity`,
+`[Command]`, `[SyncVar]`, `NetworkServer`, or anything under `UnityEngine.Networking`. (Mirror is a
+community fork with a UNet-like API; if a repo uses it, name it, but this reference targets NGO.)
+
+### Setup & session
+
+- One `NetworkManager` in the scene, with a chosen transport (Unity Transport / UTP).
+- Start a session: `NetworkManager.Singleton.StartHost()` (server + local client), `.StartServer()`
+  (dedicated/headless), or `.StartClient()`.
+- Networked prefabs need a `NetworkObject` and must be registered in the NetworkManager prefab list;
+  the **server** spawns them: `Instantiate(...).GetComponent<NetworkObject>().Spawn()`.
+
+### NetworkBehaviour, roles, lifecycle
+
+Networked scripts derive from `NetworkBehaviour`. Use `OnNetworkSpawn()` / `OnNetworkDespawn()` instead of
+`Start` for network-aware init. Role/ownership properties: `IsServer`, `IsClient`, `IsHost`, `IsOwner`,
+`OwnerClientId`, `NetworkObjectId`.
+
+### NetworkVariable — replicated state
+
+```csharp
+public class PlayerState : NetworkBehaviour {
+    // Default: read Everyone, write Server → authoritative health.
+    public NetworkVariable<int> Health = new(100);
+
+    // Client convenience state: owner writes, everyone reads.
+    public NetworkVariable<int> SkinIndex =
+        new(0, NetworkVariableReadPermission.Everyone, NetworkVariableWritePermission.Owner);
+
+    // Hidden-from-others: owner reads, owner writes.
+    public NetworkVariable<int> Ammo =
+        new(default, NetworkVariableReadPermission.Owner, NetworkVariableWritePermission.Owner);
+
+    public override void OnNetworkSpawn() {
+        Health.OnValueChanged += (prev, cur) => UpdateHealthBar(cur);
+    }
+}
+```
+
+`NetworkVariableReadPermission` is `Everyone` | `Owner`; `NetworkVariableWritePermission` is `Server` |
+`Owner`. Default (no perms arg) = read Everyone, write Server — the right default for authoritative gameplay
+values. Only the permitted writer may assign `.Value`; a client writing a server-write variable is ignored.
+
+### RPCs
+
+NGO 2.x's unified attribute is preferred:
+
+```csharp
+[Rpc(SendTo.Server)]                 // client → server
+void FireRpc(Vector3 target) { /* runs on server; validate + apply */ }
+
+[Rpc(SendTo.ClientsAndHost)]         // server → all clients (+ host)
+void PlayFxRpc(Vector3 at) { /* cosmetic */ }
+
+[Rpc(SendTo.Owner)]                  // server → the owning client only
+void YouWereHitRpc(int dmg) { }
+```
+
+`SendTo` options include `Server`, `ClientsAndHost`, `Everyone`, `Owner`, `NotServer`, `SpecifiedInParams`.
+The **legacy** attributes still compile and enforce method-name suffixes:
+
+```csharp
+[ServerRpc(RequireOwnership = true)]  void FireServerRpc(Vector3 t) { }   // name MUST end in ServerRpc
+[ClientRpc]                           void PlayFxClientRpc(Vector3 a) { } // name MUST end in ClientRpc
+```
+
+Prefer `[Rpc(SendTo.X)]` on new code; recognize the legacy pair in existing code. RPCs are unreliable by
+default for some configs — mark reliability via the attribute's `Delivery` where consistency matters.
+
+### Transforms & movement
+
+`NetworkTransform` replicates position/rotation/scale (server-authoritative by default; an
+`OwnerNetworkTransform`/authority setting allows client-authoritative). For server-authoritative movement
+with responsiveness you add prediction yourself (NGO does not ship full prediction; see
+prediction-and-latency.md). `NetworkAnimator` syncs Animator state.
+
+### Gotchas
+
+- Only the **server** may `Spawn()`/`Despawn()` NetworkObjects.
+- Writing a `NetworkVariable` you don't have write permission for silently no-ops — check perms first.
+- `IsOwner` ≠ `IsServer`; on a listen host both can be true. Gate authoritative logic on `IsServer`.
+- Legacy RPC name-suffix rule is a compile error if violated; the unified `[Rpc]` has no such rule.
+
+---
+
+## Unreal Engine 5.x — Actor replication
+
+Replication is per-`AActor`. Turn it on (`bReplicates = true` in the constructor or `SetReplicates(true)`),
+mark properties, and register them. RPCs are `UFUNCTION`s with network specifiers.
+
+### Replicated properties
+
+```cpp
+// Header
+UPROPERTY(Replicated)
+int32 Score = 0;
+
+UPROPERTY(ReplicatedUsing = OnRep_Health)     // RepNotify: OnRep_Health() runs on clients on change
+float Health = 100.f;
+
+UFUNCTION() void OnRep_Health();
+
+// Cpp — every replicated prop MUST be registered here
+void AMyPawn::GetLifetimeReplicatedProps(TArray<FLifetimeProperty>& Out) const {
+    Super::GetLifetimeReplicatedProps(Out);
+    DOREPLIFETIME(AMyPawn, Score);
+    DOREPLIFETIME(AMyPawn, Health);
+    // DOREPLIFETIME_CONDITION(AMyPawn, Ammo, COND_OwnerOnly);   // owner-only relevancy
+}
+```
+
+`ReplicatedUsing` (RepNotify) is how you react to a change — use it instead of polling the value in `Tick`.
+The **push model** (`SetReplicatedByCondition` / `MARK_PROPERTY_DIRTY`) avoids per-frame comparison for
+high-count actors.
+
+### RPCs
+
+```cpp
+UFUNCTION(Server, Reliable, WithValidation)   // client → server (validated)
+void ServerFire(FVector Target);
+bool ServerFire_Validate(FVector Target) { return Target.SizeSquared() < 1e8f; }
+void ServerFire_Implementation(FVector Target) { /* server applies */ }
+
+UFUNCTION(Client, Reliable)                    // server → owning client
+void ClientNotifyHit(int32 Dmg);
+
+UFUNCTION(NetMulticast, Unreliable)            // server → all relevant clients
+void MulticastMuzzleFx(FVector At);
+```
+
+- `Server` RPCs run on the server, callable by the owning client; add `WithValidation` for gameplay-critical
+  ones and reject cheating inputs in `_Validate`.
+- `Client` RPCs run on the actor's owning client only.
+- `NetMulticast` runs on the server and all relevant clients — cosmetic events; keep unreliable.
+- `Reliable` vs `Unreliable`: reliable is guaranteed+ordered but can saturate; reserve for gameplay.
+
+### Roles, authority, relevancy
+
+- `HasAuthority()` → true on the server (or standalone). Guard server logic with it.
+- `GetLocalRole()`: `ROLE_Authority` (server), `ROLE_AutonomousProxy` (the owning client's predicted pawn),
+  `ROLE_SimulatedProxy` (an observed remote actor). Prediction lives on autonomous proxies.
+- **Relevancy** controls what each client receives: `NetCullDistanceSquared`, `bAlwaysRelevant`,
+  `bOnlyRelevantToOwner`, override `IsNetRelevantFor`, and **dormancy** (`SetNetDormancy(DORM_DormantAll)`)
+  to stop replicating quiescent actors. This is the main bandwidth/anti-wallhack lever.
+
+### Movement & prediction
+
+`UCharacterMovementComponent` already implements client-side prediction + server reconciliation for
+character movement — use `ACharacter` and let it do the work rather than hand-rolling. For abilities, the
+Gameplay Ability System (GAS) has prediction; the Network Prediction plugin generalizes it (experimental).
+
+### Gotchas
+
+- Forgetting `DOREPLIFETIME` = the property silently never replicates.
+- RPC specifiers are directional: calling a `Server` RPC from the server, or a `Client` RPC from a client,
+  does nothing useful — respect the flow (client→Server, server→Client/Multicast).
+- Actors only replicate if `bReplicates` is true *and* the actor is net-relevant to that client.
+- On a listen server the host is authority + local player; `HasAuthority()` is your gate.