Surfaced while planning osr-web's phase-4 authored-layer adoption (mmacy/osr-web#53). Filed engine-first per the standing rule.
The gap
A gated door's success beat rides a DoorEvent that carries the party's cell and the command's direction, so the door edge — and through it the gate spec and its narrative block — resolves honestly from the event alone (LevelSpec.edge() canonicalizes either side). A gated transition's success beat rides the arrival's LocationEnteredEvent, which carries location_kind/location_id/level_number/dungeon_id/narrative and nothing naming the transition taken or the departure cell.
Why it matters downstream
osr-web's narrator (phase 4, mmacy/osr-web#53) reads a gate's authored guidance when the gate's success beat lands, by mapping the event back to the gate spec. For doors that mapping is honest. For transitions the only available "mapping" is a reverse search over the document's transitions filtered by destination and tie-broken by comparing authored success text against the event's narrative — second-guessing an answer by comparing it to the question, the anti-pattern this adoption has now documented three times (_consumed_item_phrase, the trap bearing in #67, the objective labels in #65). So transition-gate guidance is declined downstream until the event states the crossing.
This is the same emission-site-knows gap as #68's via, one level more specific: #68 asks for the kind of crossing; a gate mapping needs the crossing's identity.
What downstream needs
An additive field on the arrival event naming the transition it rode — e.g. the transition's edge key or spec id (naming and shape this repo's call), defaulting None so old logs still parse, filled by the engine at emission when the arrival came through an authored transition.
Downstream in the interim
osr-web maps gate guidance for door gates only; the spec sentence claiming "door or transition" was corrected to door-only (mmacy/osr-web#53). No reverse search over transitions will be built in the interim.
Surfaced while planning osr-web's phase-4 authored-layer adoption (mmacy/osr-web#53). Filed engine-first per the standing rule.
The gap
A gated door's success beat rides a
DoorEventthat carries the party's cell and the command's direction, so the door edge — and through it the gate spec and itsnarrativeblock — resolves honestly from the event alone (LevelSpec.edge()canonicalizes either side). A gated transition's success beat rides the arrival'sLocationEnteredEvent, which carrieslocation_kind/location_id/level_number/dungeon_id/narrativeand nothing naming the transition taken or the departure cell.Why it matters downstream
osr-web's narrator (phase 4, mmacy/osr-web#53) reads a gate's authored
guidancewhen the gate's success beat lands, by mapping the event back to the gate spec. For doors that mapping is honest. For transitions the only available "mapping" is a reverse search over the document's transitions filtered by destination and tie-broken by comparing authored success text against the event'snarrative— second-guessing an answer by comparing it to the question, the anti-pattern this adoption has now documented three times (_consumed_item_phrase, the trap bearing in #67, the objective labels in #65). So transition-gate guidance is declined downstream until the event states the crossing.This is the same emission-site-knows gap as #68's
via, one level more specific: #68 asks for the kind of crossing; a gate mapping needs the crossing's identity.What downstream needs
An additive field on the arrival event naming the transition it rode — e.g. the transition's edge key or spec id (naming and shape this repo's call), defaulting
Noneso old logs still parse, filled by the engine at emission when the arrival came through an authored transition.Downstream in the interim
osr-web maps gate guidance for door gates only; the spec sentence claiming "door or transition" was corrected to door-only (mmacy/osr-web#53). No reverse search over
transitionswill be built in the interim.