Session Prompt — WP-008 — 2026-06-03

Paste this as the first message to the executing Claude Code session. The session opens execution for WP-008 against Showdown’s cached object.ini and Scooby.eng.

Intent

Produce a logical asset catalog — tools/parse_ini.py + tools/parse_eng.py + the combined tools/samples/asset-catalog.json — that maps room IDs → objects → asset references for Showdown, and answer the load-bearing question: is the engine name-driven (string references resolved through the WP-003 name table) or index-driven (numeric references that hit TGIFILE.ART entries directly)? Land a Findings subsection under docs/formats/scooby-exe.md titled “object.ini interpreter behavior” that records the answer with concrete cross-check numbers per WP-008 Exit criterion #6.

This unblocks WP-002 (decoder verification — “entry N is the asset referenced by section X”) and gives WP-009 a canonical room-ID list for screenshot naming.

Explicitly NOT in scope for this session: any Ghidra work, any TGIFILE.ART payload decoding (WP-002), any name → TGIFILE.ART entry index mapping (that comes from WP-001/WP-002 once the exe’s lookup mechanism is known — see WP-008 §Out of scope), any Gen 2/3 work (Jinx Mummy.mms, Case File #1 Museum.MMS — different format, different WP), any Phantom Findings beyond the byte-identical Scooby.eng cross-Gen-1 note. Phantom parser runs are permitted as a stretch but outputs stay local-only — no phantom-asset-catalog.json committed.

Authority chain (read order)

Read these files top-to-bottom before doing any work:

  1. C:\Users\jjensen\.claude\CLAUDE.md — operator preferences (tone, ownership, even-handedness, commercial defaults)
  2. docs/01-VISION — engine-lineage finding, generation discipline
  3. docs/reference/wp-lifecycle — Phase 3 execution discipline + commit hygiene + the §End-to-end operator workflow steps 8–13 + the new “regenerable diagnostic outputs stay local” bullet
  4. Paired pre-flight artifact: pre-flight-WP-008-2026-06-03 — Source binary identity table + scope lock + risk review + the cross-Gen-1 Scooby.eng finding
  5. WP body: WP-008-object-ini-catalog — §Goal (truth-test framing), §Output schema (v1), §Failure handling, §Exit criteria, §Notes (deterministic naming rule)
  6. EC body: EC-004-object-ini-catalog — six time-boxed steps; Step 1 contains the parser-mode-lock gate that governs the rest
  7. Format doc to update: docs/formats/scooby-exe — current state; the new “object.ini interpreter behavior” Findings subsection lands here, NOT in tgifile-art.md
  8. WP-003 baseline (read-only input): tgifile-art.md §Pre-payload region — name-table schema; regeneration recipe for tools/samples/wp003-name-table.txt
  9. Cross-check input: tools/exes/showdown/strings-ansi.txt (gitignored, locally accessible) — WP-007 strings dump, used for Scooby.eng spot-checks per EC-004 Step 4
  10. Cache reference: tools/exes/README §Showdown — SHA-256 ledger; the two new Showdown SHAs (object.ini, Scooby.eng) recorded in the pre-flight are propagated into this README in the close commit

Pre-execution checks

Confirm each before touching files:

If any check fails: STOP. Surface the failure; do not write parser code against mismatched state.

Execution rules

Scope allowlist (verbatim from pre-flight §Scope lock):

tools/parse_ini.py
tools/parse_eng.py
docs/formats/scooby-exe.md
docs/execution-checklists/EC-004-object-ini-catalog.md
docs/reference/pre-flight-WP-008-2026-06-03.md
docs/sessions/session-WP-008-2026-06-03.md
docs/work-packets/WP-008-object-ini-catalog.md
docs/work-packets/WORK_INDEX.md
tools/exes/README.md   (Showdown §Additional cached text files — propagate two SHAs; no other section)

Allowed but local-only (gitignored under tools/samples/* per the comment block widened in b279351):

tools/samples/asset-catalog.json
tools/samples/unmatched-assets.txt
tools/samples/wp003-name-table.txt   (regenerated input from WP-003; may already exist locally)
tools/samples/phantom-asset-catalog.json   (conditional — only if Phantom stretch is exercised; never staged)

Forbidden:

Generation discipline (REQUIRED): every Finding subsection labels its source as #### Gen 1 (Showdown). The cross-Gen-1 Scooby.eng byte-identical observation may be stated as spanning Showdown+Phantom because it’s a SHA-level fact already in the pre-flight — but any interpreter-behavior claim stays Gen-1 (Showdown)-scoped.

Copyright posture: the catalog JSON contains verbatim asset-name strings and resolved Scooby.eng text extracted from copyrighted game data — keep it local-only per the §Allowed but local-only block above. Findings prose in scooby-exe.md cites counts, patterns, and structure (room count, section structure, match rate, mode selection) — never verbatim asset-string dumps. Parser scripts themselves are factual (parse a file format) and commit safely.

Commit conventions:

Top risks (imperative form from pre-flight §Risk review):

Session task

Execute EC-004 in order, treating each step’s time-box as a soft budget and Step 1 as a hard gate. Land outputs per WP-008 §Exit criteria.

  1. EC-004 Step 1 — Manual structure survey + parser-mode lock (gate). Open tools/exes/showdown/object.ini in a text editor. Walk the EC-004 §Manual structure survey checkbox list (section headers, key-value separator, section types, asset-reference format). End with the parser mode lock: record selected mode (MODE_A/B/C/D) and one-sentence justification. Outcome: parser design is decided before any code is written.

  2. EC-004 Step 2 — Parse rooms. Create tools/parse_ini.py implementing room sections only first (ID, display name, exit map, list of objects). Run it on Showdown’s object.ini. Verify room count matches manual count of section headers. Print 3-room excerpt; confirm structure. Fix parse errors before proceeding.

  3. EC-004 Step 3 — Extend to all entity types. Add object sections (graphic refs, sound refs, cursor flag), cursor definitions, inventory items. Run full parse; zero parse errors. Spot-check one familiar room’s JSON entry. Enforce the v1 schema and the failure-handling policy from WP-008 §Scope — synthetic-input checks for duplicate IDs and unknown keys ship with the script.

  4. EC-004 Step 4 — Parse Scooby.eng string table. Open tools/exes/showdown/Scooby.eng in a hex viewer first. Record delimiter pattern / message-ID type / text encoding in the EC slots — do NOT infer them from the parser working. Create tools/parse_eng.py. Parse to {message_id: text} JSON. Spot-check 5 IDs against tools/exes/showdown/strings-ansi.txt.

  5. EC-004 Step 5 — Cross-reference + write combined output + name-table cross-check metric. Walk the object.ini catalog; resolve any message-ID-shaped value via the Scooby.eng table. Write tools/samples/asset-catalog.json (local-only). Validate with python -m json.tool. Then run the name-table cross-check against tools/samples/wp003-name-table.txt: record total / matched / unmatched / rate %; export the unmatched list to tools/samples/unmatched-assets.txt (local-only); note whether ≥95 % match rate (engine is name-driven) or below (record as a new unknown for WP-001).

  6. EC-004 Step 6 — Findings note in scooby-exe.md. Add a subsection titled “object.ini interpreter behavior” under §Findings. Must answer (and concretely cite the SHAs):
    • Source binary identity: Showdown object.ini SHA 027928BB0219B9EADFEC1E066278D9BD3521B48B3E2D420DD7FEA69558A41C49 (25,196 bytes); Showdown Scooby.eng SHA EE9BE93A024FF9B7F5EA1C2445B711FB7C13CEF61A079A4609EDF1201CBAB19B (2,823 bytes — byte-identical to Phantom’s SCOOBY.ENG, cross-Gen-1 finding recorded in the pre-flight)
    • Section structure: confirmed room/object/cursor/inventory divisions (and any unexpected sections found)
    • Asset reference format / parser mode selected: MODE_A/B/C/D + justification
    • Room count + object count + cursor count + inventory count (concrete integers)
    • Cross-check metric: total / matched / unmatched / match rate %; interpretation (name-driven vs index-driven vs encoded)
    • Failure handling synthetic-input checks confirmed (duplicate-ID, unknown-key, malformed-line)
    • Data-driven vs implicit: brief estimate of how much game logic is in object.ini vs. presumed-binary

  7. Propagate the two new Showdown SHAs into tools/exes/README §Showdown. The pre-flight noted these are recorded for the first time. Add them under the “Additional cached text files” bullet so future readers find them in the cache ledger, not just in this pre-flight.

  8. Commit Commit A (docs: WP-008 — object.ini + Scooby.eng asset catalog parsers + Findings).

  9. Update WORK_INDEX — flip WP-008’s Status to ✅ Done (date 2026-06-03), actual effort recorded. Annotate downstream rows: WP-002 first-decode-strategy gets a name-driven-vs-index-driven note; WP-009 gets a “canonical room-ID list now available” note; §Current state pointer updates to next unblocked WP (likely WP-009 or WP-010). Commit as Commit B (docs: close WP-008 — flip to ✅ Done).

Outputs this session MUST produce:

  1. tools/parse_ini.py + tools/parse_eng.py (committed)
  2. Updated docs/formats/scooby-exe.md with a new “object.ini interpreter behavior” Findings subsection answering all bullets in step 6 above, two source-binary SHAs cited
  3. Updated docs/work-packets/WORK_INDEX.md with WP-008 row at ✅ Done + downstream annotations + §Current state pointer
  4. Updated docs/work-packets/WP-008-object-ini-catalog.md body with Status → ✅ Done, actual effort recorded, Findings-landed link
  5. Updated docs/execution-checklists/EC-004-object-ini-catalog.md with every checkbox slot filled (parser mode + justification, Scooby.eng delimiter/ID/encoding fields, four cross-check numbers, entry counts) — no __ placeholders left behind
  6. Updated tools/exes/README.md §Showdown with the two new SHAs propagated
  7. Updated docs/reference/pre-flight-WP-008-2026-06-03.md §Lessons learned (one line or “No lessons learned”)
  8. Local-only (gitignored): tools/samples/asset-catalog.json, tools/samples/unmatched-assets.txt

Outputs this session MUST NOT produce (sprawl guard — log as follow-up candidates instead):

Close ritual

When all WP-008 §Exit criteria (six of them) are satisfied:

  1. Confirm outputs landed. Every file in the §Scope allowlist has the expected change. The Findings subsection in scooby-exe.md answers all bullets in §Session task step 6 with concrete numbers; the SHAs are cited; the parser mode + cross-check metric are both recorded.
  2. Confirm raw extracts gitignored. git diff --cached --name-only shows zero tools/samples/** content files and zero tools/exes/** content files.
  3. Verify the two-commit topology is on main. Commit A = parsers + Findings + EC fill-in + README SHA propagation; Commit B = WORK_INDEX flip + downstream annotations.
  4. Propagate to dependent WPs. Note in WORK_INDEX §Current state that WP-008 baseline is landed; update WP-002’s first-decode-strategy note if the cross-check confirmed name-driven; update WP-009’s row to reflect that canonical room IDs are now available.
  5. Update the lessons-learned section of the pre-flight artifact — either “No lessons learned” or one line on any preventable gap pre-flight should have caught (parser-mode-lock effectiveness, schema-drift surface, cross-check-metric recording discipline).
  6. Push to origin/main (per wp-lifecycle triage off-ramp fix — direct-to-main commits need git push origin main for GitHub Pages to rebuild).
  7. Report back to operator. State: outputs landed, six exit criteria satisfied, status flipped, pushed. Lead the report with the single most load-bearing answer: is the engine name-driven or index-driven? Surface anomalies as follow-up WP candidates.

If any §Exit criterion is NOT met: WP-008 stays 🚧 In Progress. Do NOT flip WORK_INDEX. Document what’s open in WP §Notes and report back honestly.