open-questions: the replicant-side TakeDamage delivery mechanism (inst=R executions vs ENTITY.cpp reroute) -- consequences gated by #162, cause unmapped

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
This commit is contained in:
Joe DiPrima
2026-08-11 00:36:35 -05:00
co-authored by Claude Fable 5
parent 77bb54d333
commit 94e80311f2
+16
View File
@@ -1174,3 +1174,19 @@ Gitea #116 and `experience-levels.md`.
- **des_night-family pages have subtle fog deltas** (both sets near-black); arena/polar night
pages carry the dramatic 5↔40 near-plane swing. If testers report "searchlight does nothing"
on some maps, it's page authoring, not the mechanism.
## Replicant-side TakeDamage delivery -- mechanism uncharacterized (2026-08-11, from the #162 audit) [T4]
Replicant mech copies demonstrably EXECUTE `Mech::TakeDamageMessageHandler` (matchlog `DMG
inst=R` rows; the #150 bench observed replicant-side type-2 arms) -- yet every damage producer
uses `Entity::Dispatch`, and ENTITY.cpp:235-272 reroutes a replicant target's dispatch to the
wire WITHOUT local execution. Something delivers damage to the local replicant copy anyway
(wire-seam double-delivery? interest/watcher path? a port-side mirror?), and the 2026-07-25
corpus saw 0 of 18,818 DMG rows inst=R -- so the behavior APPEARED between then and 2026-08-09.
The #162 fix GATES every scoring/death consequence of it (reports + death tail are master-only),
so the scoreboard is safe regardless -- but the delivery mechanism itself is unmapped, and
replicant-side execution may have OTHER un-audited side effects (zone/subsystem state divergence
on peer copies beyond the intended visual application). To close: instrument the entry with the
delivery path (who posted it, from which socket/queue), find the first build where inst=R rows
appear, and decide whether the delivery is intended (visual-damage design) or a seam bug.