Baseline Torch build (USE_STANDALONE=ON, all games, Debug, PORT_VERSION_
ENDIANNESS=ON) reproduces every reference archive: 19 ROM dumps, all
0 failed / 0 not generated / 0 not in reference. Counts match the harness
README's 14-target table, and the duplicate dumps agree with each other,
which the 14-target matrix never showed.
Reference manifests also spot-checked by re-derivation from two o2r files
-- the baseline the gates measure against hasn't drifted.
The "filtered subset" was a misread. The log line prints the pre-recursion
yml count (1320); setup_scratch's external_files recursion then pulls in the
remaining 130, so an unfiltered run copies all 1450 - verified by replaying
the logic. So the gates use test_assets.py, the same tool that produced the
existing 14/14, with a TORCH_BIN env override as the only harness patch.
Gate A2 keeps the check.sh path, since it needs two extractions in one
process and test_assets.py execs the binary once per ROM.
Adds torch-migration/PHASE0.md with the full gate detail: what each gate's
variable is, the driver source, exact commands, cost, and exit criteria.
Two gates the plan was missing:
- Gate C (Release build) - the harness 14/14 is a Debug measurement; CI
and releases build -O3.
- Gate A2 (two extractions in one process) - free once the driver exists,
retires the re-entrancy risk offline instead of by hand in the game.
Also: gates run full-tree + check.sh rather than test_assets.py (which
hardcodes the torch path and copies a filtered yml subset), 19 ROM dumps
not 17, and libgfxd being USE_STANDALONE-only is called out as the real
hazard in Gate A.
briaguya