4. A Source and Tool Map for the MariaGO Poker AI Experiment

This final entry is a map for review and reproduction. The experiment includes a desktop C++/Qt application and a browser implementation. They expose the same problem in different execution environments, but similar names do not guarantee identical code paths or numerical behavior.

On the C++/Qt side, begin with `model`: state features, action scores, updates, and model persistence define the policy path. `game` owns street progression, betting, pot settlement, and terminal flow such as `finishHand`. `card` is where deck representation and hand-strength calculation should be checked. `mainwindow` connects the visible interface, input, and simulation, which matters when identifying the exact state represented by a log line.

The browser side has a separate web engine. It is convenient for repeated runs and action visualization, but reward logic, features, and randomness must be compared directly with native code. A constant changed in one implementation should not be assumed to have changed in the other.

Model snapshots bridge code and observation. Cheolsu, younghee, and minsu demonstrate that similar visible moves can come from different internal preferences. A snapshot is only a sample at one training point, so preserve it with filename, commit, configuration, and random seed. Do not infer an entire strategy from one weight; trace the feature vector and action-selection function too.

A practical reading order starts where chip delta is computed at hand completion. Inspect the transformation in `finishHand`, follow the value into episode updates, load the saved weights, and compare resulting action scores. Finally replay equivalent initial conditions in the Qt interface and web engine. Record implementation differences as experimental variables.

The scope is important: this published source is a diagnostic snapshot of the policy-collapse investigation. It does not claim that the proposed reward redesign, mixed-opponent training, or improved credit assignment has already been implemented or has fixed the behavior. The guard shown earlier is containment, not a root-cause repair. Any follow-up change needs its own commit and the same seeded evaluation protocol.

The map is meant to let other developers recheck the observation without overstating it. Source, snapshots, reproduction settings, and failures together form the baseline for the next experiment.