spike(vanilla): measure the pre-respawn death signal and mid-fall teleport (1.21.11)

[stellarfeline]

What this is

A measurement PR, not a feature. Two facts about pinned vanilla 1.21.11 were
about to be assumed by a design in flight; this answers both on a live server and
commits the rig plus the raw data so the answers can be re-checked rather than
re-remembered. No engine, DSL, campaign or CI behaviour changes.

Shape follows the existing precedent, tools/spike-jump-arc/: a throwaway server
from the pinned image digest, a mineflayer bot as the instrument, findings in
docs/notes/.

The two answers

Q1 — is there a pre-respawn death signal, and is the death position readable?
Yes, for every cause measured (void, fall, drowning, lava, mob kill) — but not
through an advancement, and the premise in the task was wrong on that point:
the engine's edge is a vanilla deathCount scoreboard criterion, not an
advancement. deathCount and LastDeathLocation are both written on the death
tick and stay readable for as long as the player leaves the death screen up; the
corpse's Pos is stable there too and agrees with LastDeathLocation. The one
advancement trigger that names a death, minecraft:entity_killed_player, fires
only for the mob kill and never for the four environmental causes.

cp_respawn_check is not late by accident: the bare score edge is armed on the
corpse in every trial, and it is the unless data entity @s {Health:0.0f} guard
that defers the fire to the first tick after respawn. Anything that wants to run
effects at the moment of death keys off the same edge without that guard.

Q2 — how does fall damage settle for a player teleported mid-fall?
/teleport does not touch accumulated fall distance. after − before was exactly
0.0000 in 46 of 46 teleport trials, including teleports 143 and 157 blocks
straight up, and the carried value is charged in full at the destination
landing (floor(fall_distance) − 3, fitting every trial). An arriving lift car
does not catch a falling player; it is the surface they die on — the sweep puts
the boundary between a measured survival at 20.279 blocks of accumulated fall and
a measured death at 23.435.

Incidental findings that are live defects in this repo

• 1.21.11 renamed the whole gamerule registry to snake_case, and a legacy
  camelCase name is rejected — the command changes nothing and says so to a
  response nobody reads. Two places still emit the old names:
  crates/admit/src/gallery.rs (four rules, so the gallery world cycles day and
  weather, spawns mobs and does not immediate-respawn) and
  tools/spike-jump-arc/measure.mjs:186 (gamerule fallDamage false, whose
  comment claims the jump bot takes no fall damage — it does). Not fixed here;
  fixing them is not this PR's job and both want their own change.
• A respawned player is invulnerable for 59 ticks (≈3 s), during which
  /damage is refused with an explicit message and /kill answers "Killed
  " and does nothing. This started as an intermittency in the rig's own
  scrub step and was root-caused rather than re-run away.

Full detail, per-cause tables, and an explicit list of what was not measured:
docs/notes/death-and-teleport-spike.md.

What CI proves

Nothing new — the spike is deliberately not wired into CI (same as
spike-jump-arc; docs/reference/tools.md §10 says spikes never enter a skill
or a job). The existing gates still pass, including
tools/check-compose-isolation.py: the rig publishes an ephemeral loopback
port and never takes 25565 or the mutex, so it runs alongside any worker ladder.

Reviewing this

The claims are checkable without running anything: every number in the note comes
from tools/spike-death-teleport/observations.json, which is committed with the
per-sample raw data (not just summaries).

---

🤖 Generated with Claude Code

https://claude.ai/code/session_01AjQ5p1Kv5MrkGPumi7yXWL