docs: close route 3's autorun-cancel gate — verified live, correcting my own note

An earlier revision of the gate-results section recorded route 3's autorun
cancel as live-unverified, because the first three portals all reported
autorun=unchanged. That was true of those three and wrong as a conclusion: the
user portalled again with autorun engaged and the fourth line reads

  [local-tp] cause=portal host=graphical status=Committed gen=5 seq=4
  dest=0x00070145 resolved=0x00070145 hookTail=ran leash=armed
  autorun=cancelled

This verifies the PlayerTeleported @0x006B32B0 SetAutoRun(0,1) +
SendMovementEvent port in live play. It was a real gap before this slice —
nothing cancelled the J5.4 autorun latch on arrival, so auto-running into a
portal left you running on the far side where retail stops you.

All four load-bearing fields on that line read correctly: Committed,
hookTail=ran (inversion B — the local teleport_hook runs AFTER placement,
opposite to 4b-3's remote arm), leash=armed (inversion A — the leash IS armed
here, opposite to route 2's ForcePosition rule), and autorun=cancelled.

Route 3's connected gate is now fully exercised. Route 7's remains thin (one
cause=propagate) and gate 4 remains unrun with an UNESTABLISHED trigger.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
Erik 2026-08-05 08:12:40 +02:00
parent 8ed4a7b24a
commit 934fe8dd2e

View file

@ -394,11 +394,22 @@ trigger was invalidated by route 7 and the replacement is UNESTABLISHED.
### Not exercised — recorded, not glossed
- **Route 3's autorun cancel never fired.** All three portals report
`autorun=unchanged`, meaning the local player was not auto-running at
arrival. The `PlayerTeleported` @0x006B32B0 `SetAutoRun(0,1)` port is
therefore live-unverified. To close it: engage autorun, then take a portal,
and expect `autorun=cancelled`.
- **Route 3's autorun cancel — CLOSED 2026-08-05, same session.** An earlier
revision of this section recorded it as live-unverified, because the first
three portals reported `autorun=unchanged`. That was true of those three and
wrong as a conclusion. The user then portalled WITH autorun engaged and the
fourth line reads `gen=5 seq=4 dest=0x00070145 resolved=0x00070145
hookTail=ran leash=armed autorun=cancelled`.
That verifies the `PlayerTeleported` @0x006B32B0 `SetAutoRun(0,1)` +
`SendMovementEvent` port in live play, and it was a REAL gap before this
slice: nothing cancelled the J5.4 autorun latch on arrival, so auto-running
into a portal left you running on the far side where retail stops you.
All four load-bearing fields on that line read correctly — `Committed`,
`hookTail=ran` (inversion B: the local hook runs AFTER placement, opposite
to 4b-3's remote arm), `leash=armed` (inversion A: armed here, opposite to
route 2's ForcePosition rule), and `autorun=cancelled`.
- **AP-144's autonomy divergence remains unreachable** (`TrySetAutonomyLevel`
has zero production callers), so nothing in this session could have
exercised it either way.