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:
parent
8ed4a7b24a
commit
934fe8dd2e
1 changed files with 16 additions and 5 deletions
|
|
@ -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.
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue