the story so farTrying to turn a PlayStation 2 game into a PC game. 24 days in.

The executable on the SOCOM II disc is 874 KB of loader. The actual game is locked in an encrypted archive next to it.

Day one, two commits, nothing runs. The first is tools: a harness that steps the PS2's CPU one instruction at a time, scripts to pull a function map out of Ghidra, and a decryptor for the archive. The second is the finding: inside the archive are two code overlays, 2.2 MB and 1.7 MB, stamped "SOCOM 2 r0001 17:22:21 Oct 11 2003". The disc's protection asks the console for its hardware IDs while it decrypts, but those IDs feed a hash nothing ever checks. So the archive isn't tied to one machine.

Howthe harness runs the console's MIPS core under Unicorn and traps the PS2-only instructions out to Python, because no off-the-shelf emulator knows them.

Butthe archive opens because of a quirk in the protection, not a defeat of it. Nothing of the game ran yet.

Thirty-five commits, and by the end the game's own code is C++ that compiles.

The protection layer encrypts 131 of its own code blocks; running the cipher offline unwraps them without a console. A fork of PS2Recomp turns the MIPS into C++, and the loader plus both overlays become one program file linked against a runtime. Most of the day went on something duller and more important: Ghidra's function map was wrong in ways that quietly corrupt everything. One 46 KB stretch of unrelated code had been folded into a single function, so calls into it landed in the wrong place and returned garbage. Normalised and re-exported: 13,261 functions. A Horizon server, the community's stand-in for Sony's long-dead online service, went up on the same PC three days before anything could talk to it.

HowGhidra writes Start, End and Size separately and they disagree for split functions; the fix recomputes End and forces the missing entry points by hand.

Butcompiling isn't running. Forcing entry points by hand also pushed the count of untranslatable instructions from about 11,000 to 114,000. That's garbage that never executes, and it's still there today.

The first SOCOM II match on this project's own server wasn't played by this project.

The Horizon server that had been sitting on the PC since the 4th finally got a client. A retail disc in the reference emulator went LOGIN, SELECT UNIVERSE, ACCOUNT LOGIN, lobby, after three protocol fixes read straight out of the decompiled client library. A second emulator, with its own memory card and its ports shifted, joined the game the first created; both pressed READY and the match launched: VIGILANCE, round timer running. Our own executable reached the front door the same night: network layer up on host sockets, key exchange and stream cipher running, the server accepting the connection.

Howhandler ids are assigned in registration order, so reading the live slot table out of the emulator's memory tells you which message is which.

Butthe match was two emulators. Ours got as far as LOGIN TO SOCOM II ONLINE, completed the handshake, and closed before asking for the universe list. Everything was on one machine, and the server is a community stand-in, not Sony's.

Every square root in the game had been returning zero.

The recompiler emitted the console's square-root instruction reading the wrong register, so the game always took the square root of register zero. The quaternion builder divided by that, saturated to the largest float there is, and the actors' orientation matrices exploded, which drained the collision pool and dropped the player through the terrain. Two more the same day: object geometry (trees, people, about 1700 triangles a frame) was arriving at the graphics chip as three identical points at the origin, and the camera's frustum test always answered "fully inside" because nothing wrote the flag register it read. That's where the giant sky polygons came from. The next day, the title screen's labels stopped getting wiped by the background movie painting over them a step early.

Howthe geometry fix is one rule: copy the whole packet when the program kicks it, the way the emulator does, instead of modelling the transfer a word at a time.

Buteach of these was settled by looking at the picture and at dumped memory against the emulator. There was no test suite and no gate until two days later.

The part of the console that draws SOCOM II's geometry was being simulated one cycle at a time.

The vector unit that transforms and lights every triangle was emulated at about 100 nanoseconds per cycle, which held the whole game to a few frames a second. A fast path that drops the per-cycle scheduler took that to 18 ns; a translator that turns the game's vector microcode into C++ took it to 10 offline. With the graphics and scheduler work that followed the same day, in-mission speed went 12.7, then 19, then 22-29, then 28.7 fps. Fast enough to play: a script drove the first mission end to end, walking, turning, firing, with the game answering at 36-42 fps. The same day the project wrote down what "playable" would have to mean before anyone could claim it: a match ended by a shot.

Howthe fast path and the generated code were checked against the exact interpreter, same packets, same registers; the mission program was regenerated from 900 recorded dumps of it.

Butnumbers from one PC on one mission, not a steady-state figure. One part of the speed-up was wrong: the decision to stop counting the drawing unit's time against the game's own clock was reverted on 2026-09-17, and it's a story of its own below.

SOCOM Unzipped, a test suite that runs, and one command that says PASS or FAIL.

The work moved into its own repository under the name SOCOM Unzipped. Until this day the unit tests had never been built with the project's own toolchain; once they were, 425 passed and ./build.sh test exited zero for the first time. A single gate command boots the game three times (title screen, the transition into a mission, the mission itself), scores each, and returns a number. Its first run passed two of three: the mission never reached the HUD.

Howthe suite also replays recorded drawing programs against a committed golden state file, so a change that alters output by one register is caught offline.

Buta test count isn't correctness and neither is a green gate. The gate proves regression, meaning the game looks like it did last time, and one of its three stages turned out to be measuring nothing at all. Next entry.

The drawing program is no longer emulated microcode. It's C++ someone wrote by hand.

Reading the game's vector microcode showed one dispatcher at a fixed entry point does all of it, and its commands fall into families: flat interface panels first, then world objects with clipping and multi-pass work. Hand-written replacements were checked command by command against the original, and the dispatcher went on by default after a gate that passed all three stages. By evening the world-object families were native too: 123 of 166 recorded command lists, each matching the emulated version exactly.

Howprograms are matched by a hash of their code plus entry point; anything the hand-written version doesn't handle is handed back to the emulated path part-way through a list.

Butthat clean gate was less clean than it read; see the next entry. And handing a list back part-way is exact only by luck of the recorded set: no program in it branches on the flags in the four instruction pairs where it would matter.

Someone reported black tiles flickering over the movies. The tiles were real, and they were never in the movie.

The decoded movie was perfect. Two threads shared one note of which rectangle of the screen had just changed; the game thread kept overwriting it, so the copy to the graphics card refreshed the wrong patch and left stale black squares on the intro and the title's moving background. Deleting one line fixed it. A checker written before the fix counts blocks that are black on screen but not in the decoded frame: nine before, zero after, and the missed refreshes went from 3,748 to none.

HowexecuteUpload on the render thread read m_currentTransfer, which BeginTransfer on the game thread was also setting.

Butthe predicted cause, rectangles arriving half-delivered, accounted for none of the 3,748; the planned fix would have done nothing. The checker itself ran in nothing until 2026-09-17, when it went into ./build.sh test against a committed fixture.

The game rolls dice in 249 places. For the whole life of the project, every roll had come up almost the lowest number it could.

SOCOM II turns a random draw into a fraction by dividing by two billion. The stand-in for the C library's random function returned fifteen bits where the game expects thirty-one, so every fraction landed in the bottom 1/65536 of its range. Worse, the game seeds itself from its own previous draw, and that seed froze at 41 on the first boot. One measured field that mixes in randomness went from 4.000021 to 5.5314, against 6.3338 on the real console. Same afternoon, same shape: five maths routines wired to the wrong registers, handing back whatever the previous call left behind.

Howthe stub now runs newlib's own generator over the guest's own _rand_next word rather than the host C runtime's.

Butnothing caught either of these for weeks. The parity gate was green over them the whole time, because a defect present in every run looks exactly like the reference. The maths routines were milder than billed: 19 of their 22 call sites happened to want the identity anyway.

For two days the online round had been written up as waiting to start. It wasn't. The round was running and the player was pinned.

On the 10th, with the fast build in, two instances got all the way into online gameplay, and then nobody moved. A network trace showed the two copies talking at about a packet a second, and the write-up called the match stuck at the round start. Wrong. In a multiplayer match the game scales your movement by how recently the network was active; the stand-in for the PS2's network interface answered "how much traffic have you seen" with a constant, so the game decided the network had been silent since boot and scaled movement to zero on the first frame. Looking up and down still worked, because that isn't one of the three fields the scale touches. The fix returns a real byte count. One match then carried both legs at once on one binary: one instance with the fix, one with it deliberately off.

HowsceInetInterfaceControl code 0x200 now returns a live monotonic byte count instead of a hard-coded zero.

Butan hour and 46 minutes earlier a different commit had announced the cause, and it was wrong: three calls matching three dead controls was a coincidence, withdrawn the same day. Both facts that disproved "stuck at the start" (the round clock kept running; look worked) had been sitting in the same paragraph as the claim the whole time.

Five beliefs died by measurement in one day. So they were written down where they'd been read.

KNOWN.md is a living list in four parts: what's proven and by which artefact, what's only believed and which experiment would settle it, what was retracted, and what will bite again. On the day it was created it already carried six dead sentences, among them that the console showed the same frozen match ours did, that the online round was waiting for a go, and that a higher render scale would sharpen the HUD. The next night the retracted sentences were struck in place, inside the documents where fresh sessions were still reading them, rather than quietly deleted. One follow-up commit is titled "I broke my own rule".

Howthe rule adopted the same night: cite item names and dated entries, never file-and-line, because line numbers rot the moment anyone edits above them.

Butthe file's own first note admits its first three retractions were still false in the tree hours after being disproved. The rule is retract on discovery; the practice was close-out, a day late.

On one map both players froze where they spawned. The ground was there. The game couldn't find it.

The game asks every frame whether there's ground under your feet, and online it stops you moving if the answer is no for 0.6 seconds. On Frostfire the answer was always no. The level's ground pieces had been filed into the lookup grid at the coordinates they hold before being moved into place, so every check searched the wrong squares. One missing constant: a hardware register that's always (0,0,0,1) on a real PS2 read as all zeros on every thread but the main one, and the level loader runs on another thread. After the fix both players moved for a full 302-second round and the ground check hit on every one of its 1332 and 1428 calls.

HowR5900Context() zeroed VU0's vf0, so vmaddw.xyz vf9, vf7, vf0w in the bounds transform silently dropped the translation term.

Buttwo earlier explanations were retracted on the way: a leftover "ghost" byte (the chain is real; it never fired) and an exhausted lookup grid (503 nodes used, 7689 free). And the fix rested on one usable run until the kill session below supplied a second.

A frozen picture with a running clock isn't a hung game. It's a queue.

In single-player the game thread recorded drawing commands faster than the graphics thread could replay them, and nothing pushed back. The backlog grew from 275 MB to 13 GB in four minutes; the picture updated once every 5 to 25 seconds while the game underneath ran normally. The game thread now waits at its own frame boundary whenever more than three frames are recorded but not drawn, capped at two seconds. A full mission afterwards peaked at 299 MB and never hit the cap.

Howthe wait sits at the recorder's VBlankStart, not in Present, because Present already runs on the graphics thread.

Butthe first version of the brake latched shut (a busy but healthy graphics thread looked stalled), fixed in review the same day. And back-pressure means the game slows when the host is busy, which made the parity gate sensitive to whatever else the PC is doing.

A round would start, the clock would count down, and nobody could move. The renderer was eating most of every second.

The brightening fix had a cost nobody saw for a day: it minted a fresh id for every palette the game loaded, and SOCOM II alternates palettes on consecutive draws. An online round reached 55,483 cached textures and 64,000 uploads a second; the render thread fell to two fps and the game's clock crawled at 0.04 seconds per real second. STARTING ROUND sat on screen and never cleared. Keying palettes by content put the cache back to 292 entries and the round back to 43-45 fps. The other half was older and quieter: since the 8th the game's timers had been told to ignore time spent drawing and waiting for the renderer, about 195 and 290 ms out of every second, so the whole game had been running at roughly two-thirds speed. It counts wall time now.

Howa bisect over four of the project's own launches found the regression; the old behaviour survives behind PS2X_CLOCK_EXCLUDE=1 for an A/B.

Butthe clock change's own run failed the transition stage, because that stage's black-frame floor had been calibrated on the slow clock. Recalibrated, test first. The freeze it fixed was the project's own regression, one day old.

It had never made a noise. In one day it got effects, voices, mission music and a title theme.

Four steps. A host mixer that runs the game's little sound scripts and its synth voices, so the menu clicks land. Then mission voice-overs and music, read straight out of the disc image. A 32-bit file seek had been failing silently past two gigabytes, which is why no mission stream had ever played. Then the title music, which the game decodes itself into a ring the sound hardware plays: nineteen instrumented runs to get right, because the first fix stopped the decoder when the game refused a packet, and this game treats a short read as "finished" and then polls an empty decoder 340,000 times a second. With the decoder always taking its whole input, the output matched the disc's audio at a correlation of 0.99, and a fourth fix took the title loop to 1.000.

Howrefused audio is copied aside and re-offered in order before newer audio, so nothing is lost and nothing stalls.

Butall measured against the disc, not heard. The owner's verdict partway through: "still nowhere near accurate; the opening video seems okay; mission audio good". The first ten seconds of each stream still filled short.

The front door stopped assuming everyone owns the same controller.

A list of the pads that are plugged in, the chosen one drawn live as you move it; a frame-rate line; detail, resolution and volume; a microphone. One pad selection and one dead zone now serve all three places in the program that read a controller. Before this every one of them took the first pad it found. The same day the online sprint merged, carrying the fix that finally made driven online runs reliable: the automated lobby had been reaching gameplay 6 times in 10, and went to 10 in 10.

Howthe harness's 90 ms press was falling between two polls of a login screen running at 12-30 fps; a 2 ms sampler now latches every press until a poll has seen it.

Butthe pad settings are proven by tests and one scored run. Nobody has held a real pad and said they feel right.

The owner said the sound stopped halfway through a mission. It had.

Three complaints from one evening, three faults. Sound dying mid-mission was a playback slot never handed back: after six plays every request failed, 237 times in the owner's log. The splice and the buzz in the online menus were a ring buffer with no agreement about who had filled what. The biggest sat under both: a routine the game calls whenever another part of it starts up was resetting the entire sound model, unloading the sound banks that had just been loaded. 971 rejected plays in one log. A second driven mission took those to zero unknown banks and one slot exhaustion.

HowsceSifInitRpc reset the IOP model on every call rather than only the first, and a stream that ended by itself never freed its slot.

Butmeasurements of a driven mission, not a listen. The owner's verdict the next day was still no.

The planned fix was thrown out by the measurement that was supposed to justify it.

The login and lobby screens were the expensive part of the program, and the plan was to batch draw calls. A new trace split the cost term by term and put it somewhere else entirely, so the batching was never built. The texture cache was re-decoding itself every frame: any upload anywhere moved a counter, and a moved counter threw the whole cache away. Cached textures now check themselves against a hash of the bytes their decode read. Lobby decodes went 1331 a second to none; with four cores of the host deliberately busy, the login screen holds 58-60.

Howon a stale counter the same decode walk runs over current memory, and a matching hash re-stamps the entry instead of decoding it.

Butmeasured on the login screen and in the lobby, not in a mission. There's still no steady gameplay frame rate on a clean host.

Two things every finished game has, and this one didn't.

The owner tried to save and was told no memory card was inserted. The card stub had never created or even looked at a card folder. Now the first port always holds an inserted, formatted card whose folder is made on demand, free space is counted from what's actually there, and a guest path is checked one component at a time. The tests found a climbing path really did write outside the card root on Windows. A driven save wrote 12 files and 3020 KB to an empty folder, and a second launch read the profile and seven saves back with no prompt. The headset was the other one: the program answered the game's status question with the wrong number, so the game had never opened the microphone.

Howevery call merges the reply into one status word and the voice tick reopens only on a merged word of exactly 1; the program had answered 3, then 2.

Butno voice has ever travelled. All sixteen pad buttons were held for three seconds each in a live round and nothing started recording. The talk action isn't bound in the control preset the disc loads.

A new sprint with one narrow question: what happens to somebody who has never seen this before.

Every way the program can refuse now has a number and a plain sentence, shared by the runner, the launcher and the test suite. Started with no launcher at all, the runner reads the launcher's own settings. The LAST RUN line says what happened in words, and SAVE DIAGNOSTICS writes one scrubbed zip. Then the download was measured instead of guessed: a release build in its own tree, both executables stripped with their symbols kept beside them, and the folder cut to what the executables actually import. 15 of the 31 shipped Windows libraries were needed by nothing. The zip came down 15 percent to 55.7 MB, and the gate passed 3/3 on that exact stripped executable.

Howan import-closure auditor reads both platforms' import tables in pure Python and writes SHA256SUMS beside each archive.

Butthe download is unsigned, so Windows warns anyone who runs it. Two promises are believed, not proven: that a double-clicked exe lets go of its console window, and that a missing audio device is reported on screen.

The only place in the whole program where a player can talk back.

A REPORT A BUG page joined the rail, mirroring the form on the project's website: a title, what happened, an optional way to reach you, and a preview that says exactly what SEND would send. Attaching the last run's log is off by default; when it's on, the log is cut to 64 KB and scrubbed of your home folder and the folder your disc sits in. The ONLINE page gained a line that asks the server how it's doing every ten seconds. Five answers a server can give were driven against a local one in eight tests, on Windows and on the Linux job.

HowWinHTTP on Windows, a curl subprocess on Linux, certificate checks on; plain http is refused anywhere but loopback.

Butexactly one real report has ever been sent, from Windows. The project's own notes briefly recorded it as unevidenced, because the id is stored lower-case and shown upper-case, and the inbox mirror was 35 minutes stale. Found the next day.

Not one of these came out of a test. They came out of somebody trying to play.

Escape closed the game instead of pausing it, because raylib's default exit key had never been turned off; it's Start now. The Runtime Debugger opened over the game on every launch, for everyone, because it defaulted to visible. A PC pad could never crouch: SOCOM II reads how hard Triangle is pressed, and the pad reported every press as full, so the button could only go prone. And while a mission ran the launcher was still reading the pad behind it, so the aiming stick was walking a focus ring around a window nobody could see, and Start was asking for a second launch.

Howevery pad reading in the launcher now passes through one pure gate that's the only thing which knows the game may own the pad.

Butthe pause key has no test of its own; it needs a window. The crouch shortcut and the pad gate are proven by tests and unproven by hand.

Every audio measurement the project had ever made ran on a wired endpoint. The owner listens on a Bluetooth speaker.

Four hours of measuring instead of reading. Recording what Windows actually sent to the owner's JBL Flip 6 during a driven mission, next to the mixer's own output: in one minute the mix dropped out twice, the speaker 42 times, and the emulator on the same speaker zero. raylib opens the device at 10 ms periods, three of them, and under load the device thread misses that deadline about forty times a minute. The runtime now opens its own device at 20 ms x 4: same minute, same speaker, 42 down to 2. The numbers found three more on the way: every music cue was playing 2.3 dB to the right (a sign bit dropped from the pan word), the game's positioned voice lines were starting at volume zero and never being turned up (SetSoundParams never reached a stream), and stream underruns had never been counted anywhere. Ruled out by measurement, not argument: the three fixes from earlier in the week, the reverb, loop flags, master-volume writes.

Howa WASAPI loopback of the default endpoint under the driver, scored beside the mixer's dump; the device spec is pinned by a test that was watched failing at "got 10 / got 30 ms".

Butthe owner listened again an hour later: better, not done. "Stuttering, skipping a bit" walking to the first enemies, and two segments at once in the briefing. The rest of the night is the next entry.

The owner asked for an audio version of the picture test. It found something no ear had named.

The picture gate compares our frames to the console's. The new check does the same for sound: a loopback recording of the whole path to the speaker while the driver plays a step script on either target, one score per step window (level, silences, holes, splices, envelope wobble) against a console capture pinned as the reference. Its first verdict on ours was 10 of 48 windows within tolerance, and the honest windows said something specific: at the mission start the console holds a continuous floor of sound where ours is silent 69% of the time. That floor isn't a stream. It's one sound the game plays once at mission load and polls all mission long: a conductor of child sounds, driven by a register the game writes every frame, with markers and a loop. Our mixer skipped every grain type it uses. Modelled from the open 989snd reference and pinned by tests on the real block cut from the disc: the wind, the birds and the insects exist now. 10 of 48 became 31 of 48, with no mission window silent. Later the same day a reading of the original sound driver found why stems ever skipped: on the console a finished stream still answers "playing" until its slot is retaken, and the game's music manager queues the next stem on that answer. Ours answered "done", the manager dropped its cue, and every next stem began fresh or late.

Howscripts/parity/audio_parity.sh capture <pcsx2|ours> <stamp>, then compare; the conductor's grains (START/STOP_CHILD_SOUND, register tests, markers, loops) are modelled from open-goal's 989snd.

Butthe bed plays 7-12 dB quieter than the console's, the logo movies' audio is about 18 dB low at the source, and the still-playing fix is in verification as this is written. The owner's ear closes this, not a number.

Sprint 9 merged to main and got a tag. Then a scheduled job started playing rounds against the hosted server on its own.

The sprint that started as "a stranger's first run" closed with the playtest's verdict still open on the music, and the rest of it done: the release build, failures that explain themselves, the launcher finished, the server by name. Merged to main with a merge commit, tagged v0.9.0. The same morning a Windows scheduled task learned to run ladder rounds unattended and write a ledger. Its first two runs failed to create a game. The title matcher had the channel name "Channel 1" baked into its reference, and the hosted box says "US East (Ohio)". Fixed on the title words, and run three was KILL 4/4.

Howscripts/ladder_job.sh under the loop lock, tools_py/parity/ladder_ledger.py for the ledger, docs/LADDER.md for the rules; the Task Scheduler entry is created disabled until the owner names a window.

Butno GitHub release; that waits on a decision about what can legally ship. The ladder's bar is seven clean runs in a row, and the streak is one.

The repository went public on the evening of the 20th. The next day went on making that safe, and then on proving a stranger could actually use it.

A leak check now stands at four doors: before a commit, before a push, on the build service over the whole history, and on the release folder before it's archived. It rehearses on 28 planted secret shapes before every scan, and a scanner that didn't run is never a pass. A second, independent scanner reads the same history. Then a fresh clone was made to build on Windows from nothing: a pinned toolchain download of 245 MB, a build in about four minutes on a bare rented runner, the suite green. A licence inventory with a test that fails on any dependency without a row. A release workflow that makes a draft on a tag and never publishes. And the newcomer's path was run for real, from a clone of the public address into an empty folder, every command one the documentation tells a stranger to type: 42 minutes from the clone to the game on screen, about 15 GB of disk.

Howtools_py/release/leakcheck.py has six modes and three exit states; gitleaks 8.30.1 pinned by sha256 is the second opinion; scripts/bootstrap_windows.sh pins llvm-mingw, CMake and Ninja by hash.

Buta stranger can build the game, not download and play it. That's the owner's order: harden the build first, no easy player setup until then. And an audit of disc-derived bytes in the public tree found five classes of them, sized and listed; whether any of it moves is the owner's decision, not made yet.

The one step of the build a newcomer could not do had been run once, by hand, at the start of the project.

Everything the recompiler needs comes out of the player's own disc: the loader, the encrypted archive, the two code overlays inside it. That path had been walked by hand on the 4th and promised in the contributing guide ever since. Now it's one script: point it at an ISO and it pulls the files, decrypts them, checks every digest against the six the owner recorded the first time, and stops cleanly if any differ. Running it for real, from an empty game folder to a built executable, took 29 minutes and matched the owner's digests byte for byte. Running the whole newcomer path after it found a bug the maintainer's machine could never see: the toolchain bootstrap extracted into one folder and renamed it, and on a fresh clone the rename failed at the very first command a stranger types. Fixed, and the first command finally has a test.

Howscripts/disc_to_elf.sh is idempotent and self-verifying, 43 tests; the two decryption scripts became callable so one command could drive them.

Butthe recompile still reports 114,399 untranslatable instructions, the same number as on the 4th. It's garbage that never runs, and it's still there.

The most commits in a day so far, 150, and most of them written by agents that never touched the main tree.

Each job got its own copy of the repository, a bounded brief and a stop rule. The controller merged what came back, rebuilt, and ran the three-stage picture gate before calling anything done. What landed: the gate now records every input it scored against and refuses to score at all if one has drifted. A render stall that used to eat the machine, 1.45 GB of queued commands over 600 frames, is bounded at 67 MB. A test that had been failing on the build service one run in two was fixed at its root, a simulated clock that starved one thread of its turn: 50 failures in 100 runs before, 0 in 300 after. And a console-replay test that had never actually run, runs. Two regressions got through the suite and were caught only by the gate. One was a tidy-up that moved some shared state into one file and quietly made nineteen stubs share a single disc-streaming cursor; the mission never loaded, and the change was reverted whole. The other finding was about the agents, not the code: one pushed to the main branch three times against its brief. The fix is not a stronger sentence in the brief. The next worktree is handed out with no address to push to.

Howeach chunk ran in its own git worktree on a branch; a merge, ./build.sh runtime and python -m tools_py.parity.gate in the main tree paid for it.

Butthe suite was green on both sides of the state revert, 764 of 764. Only the gate saw it. And removing the worktrees deleted the toolchain through their folder links, twice, before the order of operations was written down.

About 150 environment variables could change how the game ran, and nothing said which ones a player was meant to touch.

Every one of them is now a row in one table with a class: 18 that a player's launcher can send, the rest for developers only. One accessor reads them all, a generated page lists them, and a test fails on a name without a row, a row without a read, or a read that goes around the accessor. Developer settings need developer mode; outside it they read as unset, and the start-up line names what it ignored. Eight settings that switched something on when set to zero became plain flags. The launcher stopped passing on whatever it inherited. Proven by poisoning a launch with every setting at something hostile and watching the gate pass anyway. Found on the way: the start-up line was writing the login password in clear, and a five-letter password slipped under the scrubber's six-letter floor. Same day, the mouse left the launcher and the game entirely, and the keyboard was narrowed to menus and typing for a player. The full gameplay mapping survives in developer mode only, because the harness plays the game through it.

Howps2x::knob is the one read path; --dev or PS2X_DEV=1 is developer mode; the [knobs] line in every log says what was honoured and what was ignored.

Butthe mouse block that was deleted had never had a test. The count moved three times in a day, 145, 149, 151, as the registry found reads the inventory had missed.

The pad's buttons were two tables compiled into the program. Now they're a setting, and the launcher lets you change it with the pad alone.

On the CONTROLLER page every button of the game has a cell. Press it and the launcher listens for five seconds; the next pad button you let go of becomes the binding, and the drawn pad lights up to show it. Bind a button that's already taken and it asks: swap, replace, or cancel. Restore defaults asks first, and the default answer is no. The game logs a hash of the mapping it was given and the gate pins it. Then the rest of the launcher: the guide button swaps between launcher and game; the game window wears the launcher's name, icon and colours; and the menus click with the game's own sounds, decoded from the player's disc on the first run and cached, never shipped. And the login: the launcher's player name and password now appear in the game's own on-screen keyboard, ready to confirm. That took two findings to work at all. The game's menu calls the keyboard through a tiny forwarding routine the first wrap never intercepted; and once it did, the text vanished, because the wrap's clean-up ran when the game's scheduler unwound the call, before the keyboard had read it. Three logins with nothing typed, and the ladder streak reached four of the seven clean runs the bar wants.

Howthe mapping is one table resolved from config.json per profile, with today's values as the defaults byte for byte; the four menu cues are the disc's HUDUI bank rendered through the runtime's own mixer.

Butthe remapping page is proven by tests and screenshots; the owner's hands haven't touched it. The menu sounds were rendered and measured, not heard. And the hold-to-remap gesture the owner would ask for was a day away.

A new build for one sitting, and the notes that came back were the useful kind: small, specific, and none of them from a test.

The archive was built the night before, gated on the exact executable inside it and checked for leaks. The owner played it end to end and reported as they went. The pad stopped working in the launcher after a click into a text field, because the only ways out of a field were keyboard keys. A space typed into the player name was shown in the field, saved to disk, and silently dropped before the game got it, so the login failed with nothing on screen to say why. The launcher's default window went back to the game's own 640 by 448. And the one that mattered: on a fresh install the first save failed, and the second launch worked. The build the owner played recorded nothing about it, because a failed memory-card command said nothing at any setting. Fixed first: any failure prints one line, in every build, no setting needed. That line found the bug the same night. The game lists a brand-new card by asking for its parent folder, "..", and our path checker refused that as an attempt to climb out of the card. The game read "permission denied" as a card it couldn't use. On the second launch the save folder existed, the path resolved, and it worked.

Howa trailing ".." now resolves to the card's root, which is its own parent; a ".." followed by anything is still refused, so "/../escape.bin" never names a file.

Butthe first cut of the diagnostics ruling was wrong. It reclassed two developer settings as shipping ones, believing developer settings are compiled out of a player's build. They aren't, and the suite refused the change. Fixing the actual hole, silence on failure, is what found the save bug.

The rest of the owner's notes, and one of the project's own claims that didn't survive being measured.

The owner asked for a second way to remap: hold any pad button on the CONTROLLER page and the same bind flow opens for it, with hints that walk you through it, a meter that fills as you hold, and a gold ring closing in on the control. Five buttons can't be held, for reasons the code states: the two that move around the page, and three whose press is already spent on tabs and launch. The pad drawing got redone while it was open. The join driver learned that an empty games list is a result of its own and not a failure, after it had pressed JOIN GAME four times into "There are no games to join" trying to reach the owner's lobby. Then the "blop" the owner hears on the online screens. The project's notes had charged it to one sound bank on the strength of a correlation, and the correlation had been drawn by bucketing the owner's log by line number. Log lines are not time. Measured on one clock, with the play commands stamped on the mixer's own frame counter, the bank's one-shots sit 0.2 dB against the music bed. Inaudible. Cleared. What the same instrument did find: over ten minutes on the owner's Bluetooth speaker, 31 dropouts at the speaker that the mixer's own output doesn't contain.

Howthe new drive script skips the cinematics and reaches gameplay on the existing boot chain minus about 50 seconds of dead wait; audio_dips classifies each dip as DEVICE, STARVATION or COMMAND against the log.

Buta lead, not a finding: one run, one device. It settles on a wired speaker, and that run hasn't happened. The join driver's refresh press has no visible mark, and nobody has joined a real lobby with it. And a driven hold captures almost no music, because standing still at the start of a mission plays only short voice cues; the capture that matches what the owner heard needs the drive to walk.

The program is built from about 14,900 functions the original makers left nameless. In one evening, 1,771 of them got their real names back, each with its reason written down.

The SOCOM 1 demo's names were the start. The owner moved the whole naming programme into a sprint of its own and handed it to a session running in the cloud, with no disc and no game, only the tracked function map and the tools. It worked in waves: fifteen research notes first, then one lever per note, each a rule written in code with its own measured error rate. The demo's names matched by the shape of a function's body. The class tables the compiler left behind. The text a function refers to. Who calls it and whom it calls. The menus' own tables that bind a button to the function behind it. One program writes every name, and it cannot write one without a row saying which lever found it, how strongly, and on what evidence. About 120 functions had names that morning; by night the file held 1,771. Nothing the game does changes: the recompiler reads the names only to label the code it writes, and the cloud rebuilt the whole tree to show that the labels were the only difference. No picture for this day: nothing on it drew a frame, because the cloud has no disc. The run that proves the renamed program still plays is the next morning's gate, cited here.

Howtools_py/apply_names.py is the only writer of recomp/socom2_names.csv; the recompiler's [general] names key reads it into display names only, and a census of two cloud recomp runs showed 1,771 files renamed, 0 extents moved, 0 functions dropped.

Butsix names were held back because other evidence contradicted them, and 518 more wait for a second, independent lever to agree. The cloud's numbers were claims until a machine with the disc built and ran them.

A game server can send the game on your machine a message that writes into its memory. Ours now refuses that message, every time, and both editions still pass the gate.

Sprint 13 opened the same morning the other two closed, on an audit of the whole project, six reports and 403 findings, under one rule: nothing gets carried twice. Its first job came from a private note written the day before, about what a server could do to a connected game through a record the game trusts. Before breakfast the client refused the record that writes, and an hour later the one that reads memory back. The same morning a file path the game asks for can no longer leave the disc's, the game's or the memory card's own folder, and no private address of the owner's is a tracked default anywhere in the repository. The refusal was relinked into the program and gated three of three, then proven again on both editions with the rest of the morning's merges. No picture for this entry: a refusal draws no frame.

Howthe record class and the check are written down in docs/KNOWN.md's row and SECURITY's bullet by what they do, not how, on purpose; the network path's full inventory is a private backlog row.

Buta refusal is as good as the list it covers, and this one covers two records. The community server was never the threat here; the model of a hostile one was.