## Portable evidence and launch-condition audit — 2026-09-09 The pilot now discloses recorded launch arguments: gens_fps=60, gens_experimental_60=true, gens_enhanced_mechanics=true, gens_balance_changes=0, resolution_scale=2 and vsync=true. These do not prove live effective settings or simulation update rate. Four portable sampled-field traces are linked from health-pilot.html, each carrying source hash, executable identity, wall-time read intervals and semantic limitations. Full process-memory snapshots are not included in these downloads. All source hashes matched; baseline, minimum, final value and decrease counts were recomputed from samples. Counts are 3/0/3/2 across captures 01–04. The 0 case is an idle capture, not an attack. Existing pilot numeric conclusions were not expanded. Next gameplay validation: inspect defender COM/guard settings and compare a different attack before assigning canonical damage units. ## Third attack trial and guide integration — 2026-09-09 Three attack trials now show approximately 0.6 total decrease on the candidate 100-point scale, followed by return to baseline. Trial 04 displayed 3 Hits but yielded two sampled drops (approximately 0.4 and 0.2); it does not establish three separately resolved damage events. A broader 4096-byte defender-object scan did not validate an additional health field. The 11 extracted 2nrt command rows contain no standalone normal-shuriken entry, so the observed basic action retains its own research ID and no canonical command ID. The guide and its source template now link to the pilot. Desktop/mobile navigation, image loading, overflow, trial counts and unmapped-ID checks passed. Mobile rendering was visually reviewed. Canonical guide-data.json is unchanged; the pre-existing ZIP/PDF remain earlier artifacts. ## Repeatable health pilot — 2026-09-09 Restored Training Health from Awakened Level to 100%; Naruto HUD returned to full green. The reversal filter reduced 257,865 interpretations to 3,602. Three particularly relevant big-endian float fields followed 100→35→100 (0x410508e4 and 0x45aa5a58) or 1→0.35→1 (0x41225240). The adjacent opponent candidate 0x41050950 then followed 100→99.800003→99.600006→99.400009→100 in two separate controller-X ranged trials. Naruto candidates stayed at full baseline. A third capture had no attack and no changes. Repeat-trial screenshot shows 3 Hits. This supports a provisional total change of about 0.6 on the observed 100-point scale, not yet canonical move damage. Native inputs ended with Training at 100%, X=LMB, other displayed bindings default; configuration not saved. See [readable pilot](health-pilot.html), [machine-readable evidence](health-pilot.json), and `work/isolated/health-series-summary.json`. No frame timing was inferred from wall-clock samples. Canonical guide metrics remain unchanged pending semantics and command mapping validation. ## Repeatable health pilot — 2026-09-09 Restored Training Health from Awakened Level to 100%; Naruto HUD returned to full green. The reversal filter reduced 257,865 interpretations to 3,602. Three particularly relevant big-endian float fields followed 100→35→100 (0x410508e4 and 0x45aa5a58) or 1→0.35→1 (0x41225240). The adjacent opponent candidate 0x41050950 then followed 100→99.800003→99.600006→99.400009→100 in two separate controller-X ranged trials. Naruto candidates stayed at full baseline. A third capture had no attack and no changes. Repeat-trial screenshot shows 3 Hits. This supports a provisional total change of about 0.6 on the observed 100-point scale, not yet canonical move damage. Native inputs ended with Training at 100%, X=LMB, other displayed bindings default; configuration not saved. See [readable pilot](health-pilot.html), [machine-readable evidence](health-pilot.json), and `work/isolated/health-series-summary.json`. No frame timing was inferred from wall-clock samples. Canonical guide metrics remain unchanged pending semantics and command mapping validation. ## Training health setting checkpoint — 2026-09-09 21:09 UTC Used the user-authorized five-minute desktop window to inspect Training Settings and apply Health: Awakened Level. The initial setting was 100%. On return to combat, Naruto's full green health bar became a shorter orange bar; Sasuke's bar stayed full green. This is a visible health-state intervention, not a measured damage value. Saved evidence: [initial settings](evidence/training-settings-100.png), [alternate setting](evidence/training-settings-awakened.png), [applied result](evidence/training-awakened-applied.png). Screenshot hashes and observations are in `training-observations.json`. Two read-only memory snapshots were captured. A broad stable-pair comparison produced 257,865 unvalidated 16/32-bit candidates, including 31,191 float interpretations, across 2,531 common pages. The large result does not identify health; menu activity, allocation reuse, and unrelated state remain confounders. The second snapshot followed the exclusive desktop window. No damage or frame values were added to canonical data. Next discriminating experiment: restore 100% and require candidate values to return to baseline at the same addresses, repeat the decrease, then validate a controlled hit. The isolated session currently retains Awakened Level with A=LMB and B=RMB; remaining relevant bindings are defaults. No configuration was saved. Native input stopped at the end of the access window. # Combat measurement access checkpoint — 9 September 2026 ## Later checkpoint: Training reached ### Follow-up: hit-counter response observed A subsequent controller-X input produced Naruto's ranged-throw animation, followed by a game-window capture displaying **3 Hits**. This is one observed HUD-counter result, not a validated per-move hit count or three independently measured damage events. The observation is recorded in `training-observations.json`. The later memory snapshot `../work/isolated/training-confirmed-three-hits-01.json` is not synchronized to contact. No damage or timing amount was assigned. Another desktop-input interruption prevented the next Training-settings check; the unrelated foreground-video capture was rejected. Single Match Training is now running with Naruto versus Sasuke in the village arena, an infinite timer and initially full health bars. Naruto's selected ultimate and jutsu were displayed as Wind Style: Rasen Shuriken and Rasengan; Sasuke's as Kirin and Fire Style: Fire Ball Jutsu. These observations describe this calibration setup, not a reconciled character-code mapping. The read-only probe now supports hashed snapshots of selected writable guest regions below `0x90000000`. Two idle baselines and pre-input, early-after-input and settled snapshots were captured. These are sequential reads and cannot establish frame timing. The comparison tool found 16,371 numeric hypotheses across 2,531 common 64 KiB pages. These include unrelated state; none has been identified as health. Binding controller X to LMB produced Naruto's visible ranged-throw animation. Damaging contact and any Training health restoration remain unconfirmed. A subsequent attempt was interrupted by user desktop activity and its capture showed an unrelated foreground video. The file named `training-impact-shuriken-02.json` is therefore **not impact evidence**; its filename records intended collection timing only. The game window was also partially offscreen. Moving it fully onscreen corrected the observed settings-click mismatch. Last verified temporary controls: A=Semicolon/Space, X=LMB, B=Quote/Backspace, left-stick up=RMB, Start=X/Return. No Save to config action was used. Next dependency: an unobscured, uninterrupted Training session during controlled input and contact observation. A reset procedure and independent health-field validation are still required. Two practical prerequisites now have evidence: gameplay menu input can be made to respond, and the isolated release process can be read without modifying its memory. No damage or frame values were published in this checkpoint. ## Release and isolation The tested workspace copy of `gensrecomp.exe` hashes to `ba63e513feb5f58884e83e5e7266f99bc373acf1ca93d30387b0e5ae70230ffb`, matching the previously audited release executable. It reads installed game assets and uses workspace-owned user-data and cache paths. Run configuration and process identity are preserved in `../work/isolated/combat-access-02-run.json`; runtime messages are in `../work/isolated/combat-access-02.log`. The run requests experimental 60 FPS and Enhanced Mechanics. It is an access experiment, not a baseline timing test. Effective simulation rate and mechanics remain unvalidated. ## Observed menu access 1. Launched the isolated executable with an additional `--keybind_start=LMB,X,Return` binding. 2. Observed the title screen, then a transition to Game Mode Select following mouse-drag input. 3. Restored the default Start binding in F4 settings and bound controller A to LMB. 4. Confirmed No on the optional save prompt and entered Free Battle. 5. Bound left-stick down to RMB and observed a selection change in the VS Battle match-type menu. 6. Restored left-stick down, then bound controller B to RMB; observed the return transition to Free Battle. These are operator observations from the tool captures in this task, not a standalone video dataset. Training entry, actor selection, combat reset and repeatable attack input have not been established. Do not use these actions as timing samples. Immediate post-action captures can show a state before the eventual transition. A repeated Confirm entered VS Battle while navigation was being investigated. Always inspect a settled state before retrying. Captures of an obscured game window also sometimes showed another foreground application; those captures are invalid as game evidence. Desktop input interrupted one subsequent settings action, which was not counted as completed. The session's most recently verified bindings are A=LMB, B=RMB, Start=X/Return, left-stick down=S. They were changed only in the isolated process; Save to config was not used. Middle-mouse rebinding did not complete and was canceled. ## Read-only memory access `../work/probe_guest_memory.py` opens only the executable recorded in the isolated run, checks its disk hash and the live process image path, and requests query/read rights. It does not write memory, inject inputs or suspend execution. The runtime log identifies guest virtual base `0x100000000`. Querying that guest virtual arena returned **185 committed regions**, totaling **1,820,688,384 bytes**. This is committed address-space coverage, not unique resident RAM; aliases may exist. Two 32-byte reads at guest addresses `0x82000000` and `0x82180000` both succeeded. Raw results, region protections and timestamps are preserved in `../work/isolated/combat-access-02-memory.json`. These reads establish access only. Neither address is claimed to hold health. No integer, float, identifier or byte offset has been assigned damage semantics. ## Reference-code investigation Inspected [upstream RexGlue mouse/keyboard input source](https://github.com/rexglue/rexglue-sdk/blob/c94f5ebdcb3c9d1a460ca48e04f9758448f8d518/src/input/mnk/mnk_input_driver.cpp) at commit `c94f5ebdcb3c9d1a460ca48e04f9758448f8d518`. It maintains button state and polls it for controller output. That supports investigating short-input sampling and focus as possible causes. It does not prove which cause affected this game: the shipped runtime's exact source revision has not been established. ## Next experiment Establish Training entry with settled-state observation and repeatable reset. Record the selected fighter/form, opponent, stage, mode and effective settings. Use read-only snapshots around a single isolated hit and a reset to narrow health candidates, then reject lookalikes through independent interventions, another character and a fresh process. Validate numeric type, endianness, scale, maximum health, HUD correspondence and damage/healing behavior before publishing any candidate. Validate simulation-clock endpoints separately; wall-clock or screenshot counts are not simulation frames.