Three refs cited paths under Q3E/src/main/jni that the repository does
not carry: xash3d-fwgs and SeriousSamClassic are git submodules, so the
parent tree holds pointers and nothing else. They read as the separate
repositories they are, which is what the external form is for.
Reading the last two changed blocks turned up the substance.
ETQW_GLSL_SHADER_VERSION went from .3 to .6, and the bundled
zzz_etqwbase.pk4 grew from 136061 to 141815 bytes: the size, md5 and
sha1 the profile recorded describe the pack that was replaced. The new
one is in, the old one kept as a variant for builds that still expect
it, and GameResourceUrl gained two Quake 4 mod entries along the way.
70 refs, 68 anchored and 2 external, none left to read.
The diagnostic caught a ref whose file was missing at the pin. nestopia
showed the other shape: the file is there and the line is not yet. Its
palette and database loads were cited at 2041 and 2063, which is where
HEAD carries them, against a pin four hundred lines shorter, and that
reported as a plain GONE with nothing to act on.
A cited line past the end of the pinned file that fits HEAD is the same
finding as before and now says so. nestopia's pin moved to the revision
its refs describe: 8 refs, all anchored.
The four rhythm entries pointed at fmgen_opna.cpp:1434, a blank line at
the pin as well as at HEAD. What they mean is the block above it, where
2608_ is joined to the rhythm name and .WAV and the file is opened.
Recaling refs while the pin stays put produces exactly the state the
all-or-nothing rule exists to prevent: a profile whose refs describe one
revision and whose source_commit names another. The tool manufactured it
on mariani, where three prose runs it could not rewrite kept
bump_commit refusing while eleven refs had already moved.
Asking for both writes is now atomic. The work happens on a copy, which
is promoted only when the pin follows, and a rebase is refused outright
when something visible beforehand will hold the pin: an annotated ref,
one under a mode key, or a prose run whose tokens cannot be located well
enough to rewrite. Where the block only appears after the write, the
copy is discarded and the profile is named on stderr rather than left
half moved.
mariani is back on its pin and stays at four refs to read, which is
honest: three of them have to be rewritten by hand before anything can
advance.
The two changed blocks are BOOL, TRUE and FALSE giving way to bool, true
and false, and MemInitializeCustomROM losing its void parameter list.
Which ROM is read and how is untouched. 67 refs, all anchored.
kenji-nx cited tmp/es-de/ANDROID.md:470-474, a path from the machine of
whoever profiled it. No revision of any declared repository holds it, so
profile_sync could only report it missing, every pass, forever, and no
amount of reading would ever settle it.
validate_schemas now refuses a scratch directory, an absolute path, a
Windows drive path and one climbing out of the tree, and names the
offending citation rather than the scalar that carries it. Offline, so it
runs on every push and every pull request rather than waiting for a
network pass.
The ES-DE citation reads as external now, which is what it always was.
kenji-nx is at 37 refs, all anchored: the three changed blocks were var
giving way to explicit types.
An empty file list is the one assertion here that ages unwatched. Nothing
can go missing and no ref can drift, so nothing notices when a core that
embedded everything grows a path. virtualjaguar said "No external BIOS
files are required or loaded by this core" while its source had grown
eleven filenames read from the system directory, and only a reading
found it.
fileless_audit looks for the request itself, the system directory ask, in
the sources each profile already cites. Over the 151 fileless profiles it
named eleven, of which two were covered by data_directories, six carried
an exclusion_note, and three had nothing written down at all: craft
writes its world database in that directory, dice stores the answer in a
variable no other file in the tree names, lutro hands it to the Lua game.
Each now says so.
The check settles: declared files, a declared directory, or a written
answer all end it, so what it reports is the set nobody has read yet. A
test holds the corpus at zero.
The profile said "No external BIOS files are required or loaded by this
core" and carried an empty file list. The core reads up to eleven names
from the system directory today.
Staging left retro_load_game for stage_cart_boot_rom, which tries a file
before the embedded array. BT_CUSTOM, a value the enum did not carry
when this was profiled, searches six cart boot ROM names across three
directories; BT_M_SERIES tries jagboot_m.rom. Both need 0x20000 bytes,
the size copied to jagMemSpace + 0xE00000.
The Jaguar CD BIOS is the larger addition: three name groups over five
directories, accepted at exactly 0x40000 bytes and recognised by CRC32
against 687068D5 retail and 55A0669C developer. The group order follows
virtualjaguar_cd_bios_type, then generic names, then the other type,
since a lone file of the wrong type still beats the embedded copy.
None is required, every path falls back to an embedded array. What they
buy is the real dump instead of the reimplementation. The collection
holds the cart boot ROM under boot.rom; both CD BIOSes and jagboot_m.rom
are absent and now show as gaps rather than as nothing at all.
The profile mixed vintages: most refs carried pin-era line numbers while
the Game Express note already named the HEAD position, which reads as a
blank line at the pin. Everything now describes one revision. The only
content change in the cited blocks is LoadMediaFromZipFile taking a
softpatching flag, which decides nothing about which BIOS is read.
profile_sync follows content, so a ref that drifted still anchors where
the cited text went. That is drift detection working, and it cannot
answer the only question a MAME romset ref asks: does this line declare
this set. It flagged five refs in one driver file where nineteen were
stale, the fourteen others having been relocatable somewhere plausible.
mame_ref_audit asks the stronger question and found ninety-two across
the four profiles whose upstream still moves: mame 66, mamearcade 18,
mamemess 6, groovymame 2. Each had exactly one declaration to point at.
The frozen generations, mame2009 through mame2016, come out clean, which
is the check saying it finds drift only where drift can happen.
The set name is argument 1 of the machine macro. Matching it anywhere on
the line matches every clone naming it as parent, which is most of a
driver, and comments are stripped first because a declaration can sit
behind one. A set no machine declares is reported as not judgeable, not
wrong: device archives take their DEFINE_DEVICE_TYPE shortname.
profile_sync flagged five refs in src/mame/tvgames/xavix.cpp. Checking
each entry against the line that declares its own set showed nineteen
were wrong, the whole e-kara and XaviX family: ekara cited 2956 where
the pinned revision declares it at 2878. The fourteen the tool passed
were relocatable by content, so they anchored somewhere plausible; that
is drift detection working, and it is weaker than asking whether the
cited line declares the set the entry names.
Every ref now names the CONS line of its own set at the pinned
revision, checked by matching the set name on that line rather than by
anchoring.
Saying those profiles would stay open no matter what was wrong. A dead
forge is a verifiable fact, and a fact can be recorded: upstream_gone
carries why, and the profile stops being an open problem. The refs
describe the last revision anyone could reach, which is all any reader
can ask of them.
The declaration is guarded rather than trusted, because a forge can come
back and a profile that keeps asserting a death nobody rechecks is worse
than one that fails loudly. Declared and unreachable reports as a
recorded fact; declared and answering reports as the contradiction it
is, and the profile has to be read again.
yuzu and suyu carry GitHub's 451. citron carries the loss of
git.citron-emu.org and the squatter now sitting on the .com. Each names
what was probed and when, so the next reader retraces it rather than
repeating it.
The refs carried paths from a revision newer than source_commit, so the
profiles described two trees at once. rvvm is the plain case: the file
is src/rvvm.c at the pin and src/core/rvvm.c at the revision its refs
were written against, and citing the second against the first reads as a
file that vanished.
The diagnostic added for this named all three in one pass, and each cost
one line. rvvm 3 refs, boom3 4, applewin 1, all anchored.
A ref whose file is absent at the pinned revision reported "pin revision
missing", which reads as code that vanished. When the same file is at
HEAD and the cited range fits it, nothing vanished: the ref was written
against HEAD while source_commit still names an older revision, and the
profile describes two trees at once. The reason now says so, because the
fix is the pin and not a hunt for a move that never happened.
This is the state three profiles were left in during their own
reprofiling, against a warning the repository already carries. A range
that overruns HEAD stays a plain miss, and a file absent from both
revisions is unchanged.
Refs written at the new line numbers while the pin still named the old
revision left the profile describing two trees at once. The gpu cvar is
the clearest case: at the pin it sits in xenia_main.cc, at the revision
this profile now names it moved to emulator.cc beside the code that
reads it, and citing one against the other reads as a blank line.
The rest is a plugins.toml path join that stopped embedding a backslash,
and a cvar description that says DXIL validator where it said DXIL
shader compiler. 31 refs, all anchored.
The D3D12 backend used to load dxcompiler.dll and dxil.dll and refused
to start without the compiler. It now compiles shaders through Mesa and
keeps only the signer: D3D12 rejects an unsigned shader, so
PipelineCache::Initialize stops on IsSignerAvailable() and asks for a
recent dxil.dll. dxcompiler appears nowhere in the tree any more, and
the installer extracts that one entry from the same pinned archive.
The profile still declared dxcompiler.dll required, so it sent people
after a file the emulator stopped reading. The gpu cvar moved to
emulator.cc beside the code that reads it.
flash.html, swfobject.js and manifest.json ship in the release and exist
in no revision of the source tree: the profile marks them bundled. Cited
behind the repository's own name, the resolver stripped that name and
looked for them in the tree, where they have never been. Cited behind
ArcadeFlashWeb-release they read as what they are, an artefact no
declared revision can confirm or deny. 21 refs, none left to read.
Refs were written with the repository's own name in front, so each read
as a rename to the path without it. The six changed blocks are a source
file added to the build list, XbdmModule loaded behind a console_type
check for an anti-cheat, a devkit XEX1 key compiled in beside the retail
one, a reworded log line, wider Unicode ranges for the glyph set, and a
Windows branch that picks up an already-loaded renderdoc.dll. None of
them changes a file the user supplies. 36 refs, all anchored.
emu-ex-plus-alpha carries fourteen subprojects and each holds its own
src/main/Main.cc, options.cc, EmuMenuViews.cc and system.ccm. Written
without PCE.emu/ in front, those six refs matched fourteen paths and the
directories the profile already cites could not narrow them, so each
reported absent at its own pinned revision. Every other profile in the
family already wrote the prefix. 16 refs, all anchored.
Four Switch profiles were unverifiable and said so on stderr every pass.
yuzu and suyu answer 451, citron's host stopped resolving, and
git.eden-emu.dev returns 403 to anything that is not a browser. Each
aborted its own report, so nothing could be said about any of them, and
the noise repeated on every run over the whole corpus.
A withdrawn forge is now a fact rather than a failure. GoneError covers
451, 410 and a host that does not resolve; none is retried, since three
attempts with backoff end in the same place. Those profiles land in
their own summary bucket, out of the review backlog where nobody could
act on them anyway. A 403 stays what it was, a refusal, because small
Forgejo instances behind anti-bot filters issue it routinely.
A profile can now name a source_mirror, consulted after source and
upstream so a live primary always decides attribution. Reaching it took
two more changes: a repository that refuses is muted for the rest of the
pass instead of ending it, keyed by host as well as slug because a
mirror carries the same slug on another forge; and a refused miss is not
cached, or the mute would answer for the mirror that was about to be
asked.
eden now reads from its Codeberg copy, which holds the same head and the
pinned commit: 5 refs, all anchored, where the profile could not be
checked at all. yuzu, suyu and citron have no mirror that serves
content, and now say so once instead of failing loudly.
VPX moved file location into one class. FileLocator holds the read-only
application path and the preferences path, and picks between two layout
modes from where the application ini sits: AppPrefData splits static
data, settings and tables across three roots, AppOnly keeps everything
in the application folder. The profile still described m_szMyPath and
m_szMyPrefPath, identifiers the tree no longer carries.
Script lookup changed shape with it. SearchScript walks ten locations
case-insensitively, rooted on the table's own folder rather than the
working directory, where the profile documented seven. The editor's
completion parser left that search entirely: ParseVPCore opens core.vbs
at the Scripts subfolder alone and warns when it is absent.
The PinMAME root now prefers a pinmame folder beside the table before
the global setting and the platform default. vpx.html is served by the
web server, the LiveUI no longer naming it.
Four PinMAME citations read as external again: the project word is only
recognised behind a list delimiter, and one of them sat behind "at".
41 refs, 37 anchored, 4 external, none left to read.
MIN_BIOS_SIZE fell from 4 MB to 2 MB (BiosTools.cpp:16), which is what
admits the Namco System 246/256 COH-H chip dumps: those are 2 MB where a
console image is 4. The profile still declared the old floor, so it
described a gate the code had stopped applying.
Three changes travel with it. A COH-H board is region 11 rather than 8.
Its description is built from the EXTINFO serial, because Sony left the
version and date fields identical across those BIOSes, and the three
serials the code names resolve to System 256, System 246 Rack C and the
COH-H board. The ROM window is zero-filled before the read so its unused
upper half cannot retain the previous image.
The picker follows: .7d and .8g are accepted extensions, r27v1602f a
name hint. Both dumps are already in the collection, byte-identical to
the r27v1602f members of the MAME sys246 and sys256 sets, and the .7d is
the same content as 246C.bin, which Redump catalogues as Namco System
246 Rack C with the very serial the new code maps.
97 refs, all anchored, pin moved to the revision they describe.
The cited blocks moved by seven lines and their bodies changed only
where bfunction gave way to std::function: {&DSP1::read, &dsp1} is now
memfn(&DSP1::read, &dsp1). Which ROM is loaded, under what name, size
and hash, is untouched. Diff read before the recale.
LinApple 3.0.0 moved every ROM out of hand-written byte arrays into
res/roms/*.rom, which scripts/generate_roms.sh compiles into
EmbeddedRoms.cpp behind an ENABLE_ROM_* macro. The bytes survived the
move: every hash this profile recorded against the old string literals
matches the image that replaced it.
The macros are what matters. ENABLE_ROM_CLONE_BASE64A,
ENABLE_ROM_CLONE_PRAVETS and ENABLE_ROM_CLONE_TK3000E are OFF in the
default build, so Base64A, Pravets 82/8M/8C and TK-3000 //e refuse to
start: mem_initialize finds no rom_data, names the cmake flag and the
--rom option, and returns -1. Five system ROMs the user has to supply,
none of them documented until now. The collection already held them.
Also new: icon.bmp, which the SDL frontends read from disk through the
data search path, and the J-Plus system ROM the old profile did not
list. The tree behind the old refs is gone, so the notes describe the
one that replaced it: five frontends, src/core, src/apple2, and a
program_dir still declared and never assigned.
38 refs, all anchored. 9 of 9 files present.
A ref citing a bare filename, the way prose does, was matched against the
HEAD tree alone. A file that moved since the pin then resolved to its
HEAD path, which does not exist at the pin, and the ref reported GONE
with "pin revision missing": it failed for the one reason it never
should, its own success at HEAD.
The pin tree is searched first, HEAD stays the fallback, and the rename
search carries the pin path forward as it does for any written path.
This is what the resolver already documents for prefixed and suffixed
paths; the bare-name branch was the one that did not follow it.
linapple cites Memory.cpp, src/Memory.cpp at its pin and
src/apple2/Memory.cpp today. Its refs now name where the code went
instead of reporting it missing.
Upstream moved under 145 profiles: 679 refs shifted and 452 followed a
renamed file, against 6,483 that still anchor where they were written.
The recale rewrites the located ranges only, keeping the annotations and
the sentences that carry them, and 106 pins advance in the same commit
because refs and source_commit name one revision or the profile
describes two at once.
Nothing here was guessed. The 183 refs that are CHANGED, GONE or
AMBIGUOUS are untouched, and the 57 profiles holding them keep their old
pin until someone reads the diff: profile_sync refuses to recale a
profile while any of its refs needs a re-read. trident kept its pin too,
its annotated ref being one the writer will not rewrite.
--backfill-commits and --realign-prose have always printed what they
would write. --rebase-refs and --bump-commit took the flag and printed
nothing, so the only way to read a plan was to let it happen, and the
recale and the pin had to be done in two full network passes with
--force in between.
Both now plan. The plan runs the production write path over a throwaway
copy rather than a parallel branch, so it cannot drift from the write,
and the planned bump reads the text the recale would have left: a pin
held back by prose the same pass would move is no longer reported as
blocked. One pass does both, recale before bump on each profile.
bump_commit also stopped announcing a rewrite of the pin to the value it
already held. On the corpus that was 126 of 232 announcements, which
buried the 106 profiles that did move.
SHA256SUMS.txt sat beside the artifacts it vouches for, so whoever could
rewrite a release rewrote the list with it. The packs were already
reproducible, which answers corruption and lets a third party rebuild an
archive byte for byte; nothing answered a rewritten release.
The list is now signed with an ed25519 key kept for this alone, and the
public half is allowed_signers at the repository root, so verification
does not go through the release page: ssh-keygen -Y verify against the
committed file, then sha256sum --check. Rehearsed on all three outcomes:
a good signature, a tampered pack caught by the sums, a rewritten list
caught by the signature.
The release steps sign and upload the signature, the README points a
downloader at the procedure, and the reproducibility section says what
each half proves. Rotation keeps retired lines so past releases stay
verifiable. Three tests hold the trust root, the signing step and the
documented principal in agreement.
validate.yml triggered on pull_request alone, and it holds the only
unittest invocation in the repository: deploy-site.yml stops at
validate_schemas, generation and the freshness diff. Work lands on main
by direct push far more often than by pull request, so 1,318 cases were
guarding the road almost nothing takes.
The suite and the schema check now run on both events. validate-bios and
label-pr read pull request context and carry an event guard. The
concurrency group falls back to the ref, so a push series collapses to
the tip: what stays verified is the head of main.
The path lists are spelled out per event because the workflow parser
reads no YAML anchor, which PyYAML would have accepted in silence. Four
tests hold the wiring: the suite reachable from a push, the two path
lists equal, every job reading pull request context guarded, and no
anchor in any workflow.
The field reference carried the same attribution the FAQ did:
known_hash_adler32 described as Dolphin's IPL files, when dolphin.yml
declares it on dsp_rom.bin and dsp_coef.bin. The guard now scans every
wiki page rather than the FAQ alone.
The home page and the stats export counted every file carrying a
provenance record, the provenance page and the README only the system
files. The site published 553 and 566 for the same quantity, one click
apart, and the export paired the wider count with composition.systems as
its denominator. common.count_catalog_matched is now the single source,
scoped to the systems bucket.
The FAQ had drifted from the profiles it describes: MAME pinned at 0.287
against 0.289 in mame.yml, Adler-32 attributed to Dolphin's IPL rather
than the DSP ROMs that carry known_hash_adler32, and the per-emulator
verbose report named as the only content check on an existence platform,
which skips the DISCREPANCY line the platform report raises itself.
Tests read both sides: no generator may count matches inline, and each
FAQ claim is checked against the profile or the script that owns it.
Each name is attested by a buildbot .info file, a hardware target core
list or an ES-DE find rule. Two of them resolved to no profile at all:
dosbox_staging, declared by Batocera on three targets, and
freeintvtsoverlay, shipped as FreeIntvTSOverlay_libretro.info.
vba_m keeps no cores list: no upstream calls it that. It is a legacy key
folded into vbam, which already carries the buildbot name vba-m.
Re-read at 87b176a: refs anchored from the repo root, locale bundle
loader, spa.bin resolution in the content manager, iOS patch export and
embedded.mobileprovision.
dedup.py removes a copy only when another file has the same SHA-1 and
the same name, keeping the higher-priority path, so resolution by hash
still finds the content. Verified rather than assumed: all 17268
manifest entries ship the same bytes as before, no destination gained
or lost, only the source paths consolidate. Every deleted path's content
is still held elsewhere.
12.1 MB and 48 empty directories go with them. The index and the
published artefacts are regenerated on top.
Five cartridge hashes matched no file the collection holds. A .ctg is
not a dump: convert-ctg builds it from the .dat descriptor in the
repository and the pre-0.174 MAME images scripts/setup fetches, so the
question was not which dump is right but what the pinned source
produces.
Built at the pinned commit and replayed through the canonical recipe,
three of them reproduce the held file bit for bit: cf7+.ctg,
ti-pcard.ctg and Gram Kracker.ctg. The declared values reproduce
nothing, so the declarations were the error.
TI-994A.ctg and ti-disk.ctg are what Recalbox pins by md5, and v0.16.0
builds something else. Two legitimate versions: the primary stays
Recalbox's, the v0.16.0 output joins .variants/ under its hash prefix,
and the declaration points at what it describes. All five now resolve
sha1_exact.
A destination can be declared by more than one system, bare in one and
hash-constrained in another. generate_pack resolves that with
_preferred_entries so the constrained sibling claims the destination;
generate_manifest never did, and named whatever answered to the name.
RetroDECK's bios/d2fdc.zip is the case: declared with an md5 in the
arcade system and bare under apple-ii. The pack carried the right
archive, 262 bytes reached through the MAME clone map, while the
manifest sent install.py to a 256-byte Apple II ROM. Downloading the
ZIP and running the installer gave different files.
A test now hashes every manifest entry a platform pins and compares it
against what the platform declares: 3295 entries, on the platforms whose
frontend reads the bytes. It accepts any of several declarations for one
destination, the member-composite MD5 Recalbox pins for arcade archives,
and Batocera's 29-character prefixes. Reinstating the old manifest entry
fails it.
The contributors block is the only part of the README that comes from
the network, and a refused request returned an empty list, which deleted
the section. That happened during a pipeline run and the result was
committed; the freshness check then regenerated the section and failed
on the difference.
An unavailable list now republishes the one already there and says so.
Losing it is a worse answer than a stale one, and it makes an offline
regeneration additive rather than destructive. Reverting the change and
simulating the same outage empties the section again.
Rebuilt from the complete state: 8923 files indexed, 436 emulators, and
coverage up on every platform that gained a profile. The gap count falls
from 9 to 7, the three that closed being the C128 kernal, the Cave Story
build and Supermodel's Games.xml.
Whole pipeline green on this revision: database, provenance, recipes,
data directories, hash scrapers, truth, verify, packs, manifests,
consistency and pack integrity across the twelve platforms.
Thirty profiles from the ES-DE batch, each source-verified by the
session that wrote it and passing the schema and semantic checks. Five
declare no files at all and say why in notes referenced to the code:
NGP.emu, openbor, Plastic, Swan.emu and XeniOS.
Twenty-eight files come with them, every one declared by the profile
that needs it and matching the hash it declares, with no duplicate of
anything already held: the NetherSX2 Turnip Classic assets, the Speccy
machine ROMs, the Virtual Boy homebrew the app bundles, Snes9x EX+'s
bundled game, and sixtyforce's Overrides.plist, which carries a size
and no hash because the binary never checks one.
supermodel gains the four data files it reads from its install tree,
hakux marks its controller map unsourceable now that the asset manager
is known to read inside the package, and nethersx2 sheds the two core
aliases that belong to the Turnip profiles.
The manifests moved and the table did not. Most packs grow by about
1.4 GB: a filename-agnostic core takes any file of the declared shape in
its directory, and melonDS now finds all six regional DSi NAND images
where the anchor previously settled on one. The Android app assets that
left in the same pass were small by comparison.
bios/Other/NXEngine/Doukutsu.exe held a build whose sha1 contradicts the
one the profile declares, and it is what the RetroArch, Lakka and
RetroPie manifests ship at nxengine/Doukutsu.exe. The core opens this
binary at every launch to extract the ORG music, the PXT sounds, the
stage tile attributes, the credit bitmaps and the wavetable, so the
build matters.
The collection already held the right bytes: data/nxengine, refreshed
from the buildbot's own NXEngine asset, carries a copy matching both
declared values exactly. Same size, different build. The previous one
is kept in .variants/ under its hash; nothing declared it.
bios/Commodore/C128/vice/C128/kernal-318034-01.bin held 32768 bytes
where VICE reads 16384. It was two ROMs end to end: kernal64-325182-01
followed by the Swedish kernal the name promises. The RetroArch, Lakka
and RetroPie manifests shipped it, so the file reaching users was one
the emulator cannot load.
The second half is the genuine dump, and it matches every value
vice/src/c128/c128rom.h:104 declares: 16384 bytes, sha1 925177c9,
md5 78529222, crc32 1cf7f729. The same bytes are in the VICE tree at
the revision the profile pins. The assembly is kept in .variants/ under
its own hash, though both halves were already held separately.
Supermodel's Games.xml is collected in the same pass, from the commit
the profile pins. It is the ROM database the loader parses at startup,
so without it no set resolves and the launch returns before the
emulator is built.
The published manifests still described what the builder produced before
today's fixes. RetroArch's listed 55 files from another emulator's tree -
an Android package's banner, icons and Noto fonts - to be installed into
a BIOS directory, and omitted the six regional DSi NAND dumps a
filename-agnostic core accepts.
Across the twelve platforms: 199 files no longer listed, 36 newly
listed. Generated from the committed profile set and the committed
database so the revision stays consistent with itself.
Pinning every member's metadata made packs reproducible and took the
executable bit with it. The RetroDECK pack ships the two Voxatron engine
binaries, and extracted at 644 they cannot be run.
Git records the bit, so reading it from the source file keeps a pack the
same from any clone. Nothing else about the source's mode reaches the
archive: 2569 members ship at 644 and 942 at 755, which is what the
builder produced before the pinning.
Nothing caught this. The comparison that proved the pinning inert
checked member names, CRCs and sizes, and mode is none of those. A test
now builds a runnable payload and asserts it survives extraction.
RetroDECK rebuilds to the same bytes twice and passes its integrity
check, 2008/2008 baseline and 1551/1551 cores.
The verifier and the builder each resolved the profiles a run names, in
thirty-five lines that differed only in how they failed: one exits, the
other returns empty-handed. An alias is the same binary under another
name and a launcher only starts an emulator, so neither has requirements
of its own, and both refusals have to say the same thing.
common raises now and each caller chooses its own ending. Six tests hold
the refusals, one of them reading both sources so a copy cannot grow
back. The manifest's core-complement phase comes out of generate_manifest
in the same pass, 60 to 34.
Verified inert: manifests identical entry for entry, and the Handy pack
rebuilds to the same bytes.
Abdessamad Derraz