# Proposed single-wheel prison action selection

This is an unexecuted selection-only experiment. The19:41:28 native run reached the original gate context with cached permission for the lock, but did not select the lock. No wheel event, F press, door opening or successful lock interaction is established by this document. Upcoming ordered-action diagnostics must satisfy the prerequisites below before a wheel event is authorized.

## What the installed controls and selection code establish

Installed `Configs/System/chimeraInputCommon.conf:8005–8050` defines `ActionMenuContext` with `SelectAction` as `AnalogRelative`. `mouse:wheel+` uses the `previous` preset; `mouse:wheel-` uses `next` with multiplier−1. `SCR_InteractionHandlerComponent.c:71,98–102` listens to `SelectAction` VALUE and stores the supplied value. In `OnPostFrame:733–746`, an absolute value above0.5 becomes a clamped−1/+1 step; the handler **subtracts** it from the selected index and clamps that index to the available list. There is no wraparound and no general instruction to skip disabled actions.

The native filtered list is not necessarily the final navigation list: `OnPostFrame:699–710` calls `GetFilteredActions` and then `AggregateActions`. The latter groups aggregatable entries by action name, selecting a performable representative where possible, otherwise retaining the first. Diagnostics reporting only raw filtered indices therefore cannot authorize arbitrary index navigation.

Bound the first experiment to **exactly two entries**, each matching the pinned original gate/context and unique action ID: one `ERR_PrisonDoorAction`, one `ERR_UnlockPrisonAction`. Require the currently selected ID to be the former, its cached permission false, and the original lock's cached permission true. Refuse duplicates, missing entries, a third action, changed order/identity, or an unexpected selected action. For these exact classes at closed door control0, the installed `SCR_DoorUserAction.GetActionNameScript` returns `#AR-UserAction_Open`; the successor lock's authored `PrisonDoor.et` UI name is `Pick prison lock`, with no action-name override. They cannot merge by equal name in the inspected aggregation algorithm. Thus the two raw entries retain their relative order after aggregation. This proof is deliberately limited to these classes, names and closed-door state; it is not a generic filtered-index contract.

The disabled Open entry is legitimate UI state: `ERR_PrisonDoorAction.CanBePerformedScript` refuses it during PRISON. Do not remove, disable further, reorder or bypass it to improve selection. The experiment only asks normal native input to select its adjacent lock entry. The handler activates `ActionMenuContext` when a filtered context has actions; do not activate it manually.

## XTest capability and unresolved mapping

The installed `/usr/include/X11/extensions/XTest.h:62–67` declares:

```c
int XTestFakeButtonEvent(Display *display, unsigned int button,
                        Bool is_press, unsigned long delay);
```

The installed libXtst1.2.5 `XTestQueryExtension(3)` manual says this requests a **logical button** press/release; `CurrentTime` means no requested delay. It does not promise a native game wheel-axis sign, a particular `SelectAction` value, or successful delivery to the selected action. Logical buttons4/5 are the proposed wheel candidates; do not treat the conventional4=up/5=down mapping as already verified through this Xwayland→Proton→game stack. The stock game binding establishes only what happens after `mouse:wheel+/-` is received. Existing profile remapping must not be changed.

Choose one of4/5 explicitly according to the measured adjacent index direction and the documented conventional candidate mapping; record that assumption and the intended native index change. The trial's success comes from actual lock selection, not the return value from XTest. A wrong/no-op/multiple native step is a retained failure, with **no opposite-wheel retry in the same run**. A native `SelectAction` observation, if subsequently added read-only, would explain direction but would not replace identity-based selection proof. A short axis impulse can fall between100ms samples, so an absent sampled axis alone cannot prove no delivery.

Use the same already-proven private display connection, exact Gamescope/Xwayland listener/PID/run binding, mapped focused owned game window, and pointer inside that same owned window or its verified descendant. Revalidate immediately before both button-down and button-up. No focus, raise, pointer warp, absolute/relative mouse movement, settings change or desktop fallback is permitted. XTest button delivery is governed by the pointer as well as window focus; existing focused-window proof alone is insufficient if the pointer is elsewhere.

`XQueryPointer(3)` returns current pointer button/modifier state; `/usr/include/X11/X.h` defines `Button4Mask` as1<<11 and `Button5Mask` as1<<12. Require idle keys/buttons before pressing and a bounded roundtrip confirming the chosen button released afterward. A successful request/flush alone is not release proof. Mark the attempted button uncertain before the native call. Send one bounded down/up pair with delay0; no intentional hold is needed. Preserve the existing1.5-second maximum uncertain-input supervisor lease and original observation deadline. On failure, attempt the matching release only on the same still-proven connection; otherwise record uncertainty and use existing owned-child termination/prefix cleanup. Never retry with another display, button-down or gameplay input.

## Separate facing from selection without relabeling old evidence

The existing alignment proof requires heading plus exact lock selection. It correctly failed19:41:28; do not retroactively call that alignment result successful. A new explicit variant may split the next run into:

1. **Facing proof:** after accepted approach, bounded yaw-only inputs until two fresh consecutive observations, separated by at least100ms, show measured camera-to-handle bearing error≤3°, stable view, stopped original body and the pinned original gate context. Preserve the current8-second ceiling, turn/pointer bounds, original45-second lifetime and every pose/identity guard. Stop at the first qualifying pair instead of spending the remaining ceiling waiting for an action already known to be unselected. This outcome proves facing/context only.
2. **Selection proof:** consume the exact same frozen actor/camera/life/world/nonce and gate/action identities, plus the two-entry diagnostics. Permit only the single chosen wheel pair. Continue the same deadline `min(original alignment start+8s, original observation expiry)`; a handoff cannot grant another8 seconds. Admit only with enough remaining time for the guarded pair and a bounded observation interval, e.g. at least1.5 seconds remaining; observe for no more than1.5 seconds, shortened by that immutable deadline. Freshness and ownership checks may cause refusal rather than shortening proof obligations.

Success requires two fresh consecutive observations at least100ms apart with **the exact lock selected, exact context selected, cached permission true and progressBound=true**, duration4, performing=false, progress=0, and PerformAction input0. Keep full3D body drift≤0.05m, neutral movement/turn input, closed unchanged original gate and PRISON throughout. Record all intervening samples, ordered-action identities, button attempt/release timestamps, first/last proof references and independent source/session hashes. The final validator must recompute facing from raw camera/handle geometry and selection from raw exact-action diagnostics; neither a helper `facing_complete` flag nor cached permission alone is sufficient.

If selection already matches the lock at admission, record that fact and send no wheel; it is not evidence that a wheel selected it. If diagnostics do not establish the two-entry contract, or the native selected ID changes unexpectedly before dispatch, send nothing. If the target is not selected after the one pair, stop. No F, pitch, W, inventory key or action-selection setter is available to this variant.

## Measured budget and limits

In `logs_2026-09-19_19-41-28` (nonce `594ae7cf6f8c4f1b811a8a4e619dbffb`), QUEUED was real30605ms, so original expiry was75605ms. Approach ended at sample296/real64101. Four alignment requests were128,128,128,103 horizontal pixels; the final turn's recorded settled response was sample346.

The first two native samples meeting the measured≤3° facing criterion were345/real69668 and346/real69768: view yaw164.640°, handle-bearing error2.120°, context=true and cached lock permission=true, but selected lock=false and progressBound=false. **Only5.837 seconds** of the original native lifetime remained at the second sample, before further host-side receipt/guard cost. These records demonstrate why an earliest-facing handoff avoids needless waiting; they do not prove a future wheel's latency or direction. Even successful immediate selection in this particular timing would not satisfy the separate held-F admission requirement of at least6 seconds remaining. Send no F in this selection-only experiment and do not increase45 seconds, renew clocks or relax stable-selection requirements to fit it.

A four-turn/five-second facing target is an optimization hypothesis, not an established runtime bound: this run's alignment started near real64.1s and reached its qualifying facing pair at69.768s. Keep all native response/settling requirements. Later genuine held-F work is conditional on independently measured remaining time, as described in [the held-action design](prison-held-action-design.md).

This audit inspected installed files and preserved logs only. No display connection, button/key request, native launch, input-setting change or executable-source edit was made.