Pre-Flight — WP-007 — 2026-06-02

Filled-in copy of docs/reference/pre-flight for WP-007. Verdict at the bottom.

WP: WP-007
Title: Scooby.exe strings dump + import table extract
Pre-flight date: 2026-06-02
Targets generation(s): Gen 1 (Showdown — primary), Gen 1 (Phantom), Gen 2 (Jinx), Gen 3 (Case File #1) — per vision §Engine Lineage
Targets disc(s): Showdown, Phantom, Jinx, Case File #1

Pre-flight intent

Validating readiness for WP-007. Not implementing, not editing engine code, not annotating Ghidra. Verdict only.

Dependency check

WORK_INDEX row for WP-007 shows Deps: — (no prereq WPs). The Phase 0 sequence places WP-007 first under “Phase 0 — Pre-Work (run before WP-001)” with no upstream dependencies. Vacuously satisfied; recorded here for audit.

Prereq	Status in `WORK_INDEX`	Locked on	Notes
—	n/a (no prereqs)	n/a	WORK_INDEX Phase 0 table, WP-007 row, Deps column is `—`

Rule check: no prereq is not ✅ Done, because no prereqs exist. Phase-ordering rule is satisfied — WP-007 is itself the head of the Phase 0 sequence.

Repo + disc state

Working tree clean — git status --short returns empty
HEAD on main at commit 43bbfb2 (“fix: add .md extensions to all relative links so jekyll-relative-links resolves them correctly”)
Disc-on-hand: NOT satisfied. tools/exes/ contains only README.md. None of showdown/Scooby.exe, phantom/Scooby.exe, jinx/Scooby.exe, casefile1/Scooby.exe exist. WP-007 §Dependencies requires the Showdown binary at minimum; full WP scope (cross-title runs) requires all four.
No prior Ghidra .gpr is being re-used — WP-007 is a pre-Ghidra WP
No prior tool output is being re-used — this is the first run of strings/imports extraction

ISO / extract paths in use (source ISOs confirmed present at the documented location):

Showdown    ISO: C:\pcloud\SCOOBY\Scooby Doo Showdown in Ghost Town.iso     (cached EXE: MISSING — needs tools\exes\showdown\Scooby.exe)
Phantom     ISO: C:\pcloud\SCOOBY\Scooby Doo Phantom of the Knight.iso       (cached EXE: MISSING — needs tools\exes\phantom\Scooby.exe)
Jinx        ISO: C:\pcloud\SCOOBY\Scooby Doo Jinx at the Sphinx.iso          (cached EXE: MISSING — needs tools\exes\jinx\Scooby.exe)
Case File 1 ISO: C:\pcloud\SCOOBY\Case File 1.iso                            (cached EXE: MISSING — needs tools\exes\casefile1\Scooby.exe)

Scope lock

Anything not explicitly allowed is forbidden.

Allowed paths for WP-007:

docs/formats/scooby-exe.md
docs/reference/pre-flight-WP-007-2026-06-02.md
docs/work-packets/WORK_INDEX.md
docs/work-packets/WP-007-strings-and-imports.md
tools/extract_strings.py
tools/extract_imports.py

Allowed but local-only (never committed; covered by .gitignore on tools/exes/*):

tools/exes/showdown/Scooby.exe
tools/exes/phantom/Scooby.exe
tools/exes/jinx/Scooby.exe
tools/exes/casefile1/Scooby.exe
tools/exes/<title>/strings-ansi.txt
tools/exes/<title>/strings-wide.txt
tools/exes/<title>/imports.txt

Forbidden (any change fails the WP):

Game data binaries committed to git (any *.exe, *.eng, *.dat, *.iso, *.ART) — copyright; safety-net already in .gitignore
engines/scooby/** — engine code is out of scope for this WP (scaffold is WP-010)
docs/formats/ files other than scooby-exe.md (no spec changes to tgifile-art.md, mmfw-container.md, audio-archives.md from this WP)
docs/execution-checklists/EC-001-ghidra-session.md — the WP-007 → EC-001 Step 3 hand-off is documented in WP-007’s Notes; EC-001 itself is amended later via WP-001’s pre-flight, not here
Any path outside the allowlist above

Exit check (must run before staging a commit):

git diff --cached --name-only

Any file in the output that doesn’t match the allowed list = scope violation. Remediate with git restore, not by widening the allowlist post-hoc.

Risk review

Risk	Likelihood	Impact	Mitigation
Disc mismatch / ISO drift — extraction runs against a Scooby.exe whose contents differ from the canonical disc-pressed binary (e.g. archive.org re-rip vs original press, different region)	med	high	Record the SHA-256 of every binary in the Binary identity table per WP-007 §Output spec. Re-runs against a different SHA invalidate the row. Cite the SHA-256 in `scooby-exe.md` Findings before any other claim.
Generation conflation — finding stated as “the engine does X” when X is Gen 1-only (or Gen 2-only); particular risk for the strings findings, where naming conventions may differ between TerraGlyph (Gen 1/2) and IBS (Gen 3)	med	med	Every Findings subsection labeled `#### <Title> (Gen N)`. The Cross-title delta bullet in both Conclusions blocks forces explicit comparison rather than implicit assumption.
Copyright leak — raw strings dumps may contain dialog text, error messages, or copyright marks staged into `docs/formats/scooby-exe.md` wholesale instead of categorized samples	med	high	Raw `strings-ansi.txt` / `strings-wide.txt` / `imports.txt` files live only under `tools/exes/<title>/` (gitignored). Only structured categorized samples + filename anchors + import surface reach `docs/`. WP-007 §Notes “Copyright posture” bullet is the standing reminder; `git diff --cached --name-only` check above is the gate.
Tool output non-determinism — sort order, locale, or pefile internal iteration changes between runs, producing diffs that aren’t real	low	med	Python scripts in WP-007 §Execution use `sorted(...)` with explicit keys (`str.lower` for imports) and byte-order ASCII for strings. Run each script twice against the Showdown binary, hash both outputs, confirm identical before promoting any finding into `scooby-exe.md`.
Scope creep into EC-001 Step 3 re-extraction — temptation to also document import xrefs and call-site locations during this WP, which is Ghidra-only work	low	med	The §Out of scope bullet “Behavioral analysis of imports” is the boundary. Step 3 hand-off note in WP-007 §Notes spells out the reduction to “cross-check, not re-extraction.” If a finding requires xrefs to justify, it belongs in WP-001’s Findings, not WP-007’s.
WORK_INDEX inconsistency post-completion — WP-007 row in WORK_INDEX still says “15–30 min” but the WP body now estimates “20–40 min” with cross-title in scope	low	low	Status bump to ✅ Done at WP completion also updates the effort estimate in that table cell. Already inside the §Scope lock allowlist (`docs/work-packets/WORK_INDEX.md`).

Verdict

READY TO EXECUTE
NOT READY

Reason: §Repo + disc state — the cached binaries this WP runs against do not exist. tools/exes/ is empty except for its README. WP-007 cannot extract from binaries that aren’t on disk.

Path to resolution:

Mount each ISO from C:\pcloud\SCOOBY\ (Explorer → right-click → Mount) and copy the EXE per the tools/exes/README workflow. Canonical destinations:
- tools\exes\showdown\Scooby.exe ← from Scooby Doo Showdown in Ghost Town.iso
- tools\exes\phantom\Scooby.exe ← from Scooby Doo Phantom of the Knight.iso
- tools\exes\jinx\Scooby.exe ← from Scooby Doo Jinx at the Sphinx.iso
- tools\exes\casefile1\Scooby.exe ← from Case File 1.iso (original filename Case File #1.exe; rename to Scooby.exe per the safety-net convention)
Record each binary’s SHA-256 (Get-FileHash <path> -Algorithm SHA256) — these go into the Binary identity table during execution; capture them now for the re-run of this pre-flight.
Re-run this pre-flight (new dated file, e.g. pre-flight-WP-007-2026-06-XX.md) citing this NOT READY artifact in its Header section.
Minimum to clear: Showdown binary cached + SHA-256 recorded. Cross-title rows (Phantom, Jinx, Case File #1) can be deferred to a follow-on session if needed — record the skip in the Binary identity table per WP-007 §Notes.

Reviewer: Jeff (BarefootBetters) Date: 2026-06-02

A NOT READY verdict is itself the audit artifact. The next pre-flight cites this file in its Header.

After execution — lessons learned

Not applicable for this pre-flight — execution did not occur. If structural gaps surface in the next-attempt pre-flight, amend the pre-flight template before opening the execution session.