# Proposed normal-input prison escape proof

**Implementation guidance only; this route and lock-picking input sequence have not been executed.** Extend the existing explicitly enabled private-display experiment. Use actual mouse/keyboard input and read-only native observations. Do not teleport, set transforms/velocity, select actions through script, invoke action completion, shorten duration, change controls, or remove obstacles.

## Source and starting evidence

The ordinary run [game-2026-09-19-180423-inventory-ready/console.log.txt](evidence/game-2026-09-19-180423-inventory-ready/console.log.txt), line 490, records the original player at `<6088.5,211.389,7158.5>` with neutral inputs and zero velocity. Its nonce is `a75280fda4494a0ca7b14a693cf310e9`; this is historical starting-position evidence, never authorization for a later run.

[ERR_SpawnPlacement.c](../addons/core/Scripts/Game/ERR/ERR_SpawnPlacement.c), `Prison`, searches the four inner lattice positions first; its first candidate is prison centre minus `1.5` in X/Z. [ERR_SpawnLogic.c](../addons/core/Scripts/Game/ERR/ERR_SpawnLogic.c), `DoSpawn_S`, constructs `SCR_FreeSpawnData` without angles. The installed vanilla `scripts/Game/Respawn/RequestHandling/Implementation/FreeSpawn/SCR_FreeSpawnData.c:27` defaults angles to `0 0 0`. Expected initial facing is +Z, but the experiment must read actual pose/view orientation before movement and refuse a different starting configuration rather than assume it.

[EveronSites.conf](../addons/core/Configs/ERR/EveronSites.conf) places the prison at X/Z `6090/7160`. [Prison.et](../addons/core/Prefabs/ERR/Prison.et) places the gate hinge at local `0,-0.1,-6`, scale `1.5`. [PrisonDoor.et](../addons/core/Prefabs/ERR/PrisonDoor.et) inherits the concrete vanilla metal gate's handle context offset `1.845,1.255,0`, giving an expected world handle near `(6092.7675, siteY+1.7825, 7154)`. This is approximately 6.20 m horizontally from the recorded spawn. Native `UserActionContext.GetOrigin/GetRadius/GetTransformationWorld` must confirm the actual evaluated geometry; do not assume how scale affects the configured radius of 2.

## Minimal candidate route and inputs

1. With inventory closed and the original player stationary, make a tiny bounded relative mouse movement. Require native `CharacterTurnRight`/`CharacterTurnUp` and measured view-direction change before enabling navigation. Mouse sensitivity and private XTest forwarding into native relative input are **unproven**; do not substitute an absolute cursor warp or camera write.
2. Turn toward candidate interior approach point X/Z `6092/7155.5`, roughly 4.61 m from the recorded spawn (initial horizontal heading approximately 131°). Use short W pulses, releasing and checking actual movement between them. Correct heading using small mouse movements. This point lies inside the authored walls and about 1.69 m horizontally from the expected handle.
3. Stop and aim at the **observed** handle context. Require the selected action to be the gate's actual `ERR_UnlockPrisonAction`, named “Pick prison lock.” If disabled “Open” is selected, allow a bounded wheel step and reobserve selection; never call `SetSelectedAction` or override context collection.
4. Hold F only while the exact lock/action/context/body remains valid. Require native progress through the authored four-second duration, then release F. Before any exit movement, observe PRISON → RADIO_SEARCH while the player remains inside, with the same intact gate moving open. This separates lock-picking proof from the alternate boundary-crossing progression path.
5. After the gate is visibly/physically open, use heading-corrected W pulses through the candidate opening centre near `6091.5/7154` to `6091.5/7151`. Observe continuous physical crossing south of `7152`, then neutral input. Total proposed movement is about 9 m. This is a geometry-derived route, **not a native clearance guarantee**; collision/no progress must refuse the experiment.

Installed bindings are in `Configs/System/chimeraInputCommon.conf`: W → `CharacterForward` (255), relative mouse Y/X → `CharacterTurnUp/Right` (346/380), held F → `PerformAction` (2942), wheel ± → `SelectAction` in `ActionMenuContext` (8005). The separate `CharacterAction` F-down binding is not proof of a held interaction. Additional operations are therefore relative mouse, F, and possibly wheel; A/D are unnecessary if turning works.

## Required observations and bounds

Keep the existing exact private-display/window/focus/process/prefix ownership guards before every event. Pin the new run's controller, account, body and gate. Abort on changed identity, death/unconsciousness, focus loss, gate destruction, unexpected phase/action/context, non-neutral prior input, blocked motion or exhausted budget. Do not alter guards or enemy balance to obtain a pass.

Read native `BaseInteractionHandlerComponent.GetSelectedAction` and `ExtBaseInteractionHandlerComponent.GetCurrentContext/GetFilteredActions`; confirm the original gate owns the lock, the context is in reach, native permission is true and `GetActionDuration()==4`. During F, record native `PerformAction` input and actual `SCR_InteractionHandlerComponent.m_fCurrentProgress/m_bIsPerforming` through a narrowly gated read-only accessor. `action.GetActionProgress(0,0)` **does not return accumulated progress**. The installed handler accumulates progress and invokes normal completion itself (`scripts/Game/Interactions/SCR_InteractionHandlerComponent.c:164–239`). Require multiple increasing native progress observations, original gate control-value change, phase transition, and subsequent neutral F/movement samples.

Retain existing short W/Tab safety limits. The current 1.5-second pending-key limit cannot accommodate the four-second lock: introduce an explicit **F-only maximum of 5 seconds**, conditional on fresh matching action observations, without extending any other key's lease. Use at most 250 ms per movement pulse, 12 m cumulative displacement and one attempt; budget at most 40 seconds after a fresh stationary READY, inside the observer's existing 45-second window. Reject insufficient remaining time. Release only while the original target remains proven; uncertain release must fail and trigger existing owned-session cleanup.

Capture approach/selected action, genuine progress and outside state. Preserve raw errors and all refused attempts. Even a pass qualifies one local normal-input prison exit only—not a full escape, remote multiplayer behavior, or performance improvement.