Worker w-cmdtable-a1; task cmdtable; research (read-only RE). Read .agent-cache/WORKER.md. Bus: python "%USERPROFILE%/.claude/skills/agent-cache-orchestrator/scripts/acbus.py" (identical copy at %USERPROFILE%/.agents/skills/... ; use one consistently). Two other workers run in parallel on other hosts (astra-map-v3 = map bundle, astra-save-v3 = save serialization). Stay inside your ownership.
Objective
Enumerate the TNC retail command registry from the captured runtime image and settle one question with evidence: is there ANY registered command in the retail build that loads a map by name, and if so under which name and which gate?
Measured baseline you must explain, not contradict blindly: at runtime both
map and devmap answer unknown command, even with com_enableDeveloperMode=1,
devMode_enable=1, g_demoDevMode=1. Known to work at runtime: writeConfig,
conDump, listCvars, listCvars - help. See docs/stand.md and
re_probes/agent_reports/custom_save_registration.md.
Three outcomes are all acceptable; pick the one the evidence supports: (a) no map-loading command is registered -> the save/bundle route is the only route; (b) one is registered but flag-gated -> name the flag, the check, and whether a cvar or launch argument can satisfy it; (c) it is registered and reachable -> give the exact console syntax and the argument format it parses.
Sources / starting points
- re_probes/runtime_87400/module.bin (92,188,672 bytes, layout "virtual RVA": file offset == RVA; image base 140695279042560 = 0x7FF6xxxxxxxx, pid 87400, captured 2026-09-23 00:26). manifest.json lists every section with rva/vsize. .text rva 0x1000, .rdata rva 0x1E62000, .data rva 0x2E39000.
- Absolute pointers inside .data are runtime VAs: RVA = VA - base.
- capstone 5.0.7 is vendored, no install needed: PYTHONPATH=re_probes/python_deps python ...
- id Tech heritage: idCmdSystemLocal::AddCommand(name, fn, flags, description, argCompletion) keeps commandDef_t nodes {next, name*, args, function, argCompletion, flags, description*} in a linked list plus a hash table. The public Doom 3 / idTech 4 source is a legitimate reference for the layout; verify the actual struct against this binary, do not assume it.
- Two independent attacks, use both and cross-check:
- data-driven: find the command name strings in .rdata, find .data words
pointing at them, walk the surrounding struct, then walk
next. - code-driven: disassemble .text for
lea rcx,[rip+<name-string>]feeding a common call target; that target is the registration function. Enumerate all its call sites to get every registered name plus its flags argument.
- data-driven: find the command name strings in .rdata, find .data words
pointing at them, walk the surrounding struct, then walk
- Existing string work: tools/probe_strings.py, tools/probe_devmode.py, tools/cvar_table.py (same technique for the cvar table, likely reusable).
Ownership
tools/probe_cmdtable.py (new), re_probes/cmdtable/ (new dir, all artifacts), re_probes/agent_reports/cmdtable.md (new).
Forbidden / do not touch
No launching the game, no writing to the Steam install, no writing to "%USERPROFILE%/Saved Games", no process attach or memory writes. Read module.bin read-only. Do not edit anything owned by others: tools/build_tnc_map_alias_v3.py, tools/verify_tnc_map_alias_v3.py, re_probes/map_alias_v3/, tools/build_custom_save_candidate.py, tools/probe_details_checksum.py, tools/verify_custom_save_candidate.py, re_probes/custom_save_candidates/, docs/, wolfsdk/, config.json. Do not pip install anything.
Hard constraints
Python 3.11, stdlib plus the vendored capstone only. The probe must be reproducible from the command line and must not depend on a running game.
Acceptance criteria
- tools/probe_cmdtable.py prints and dumps re_probes/cmdtable/commands.json: one record per registered command with name, flags (raw int and decoded), description if present, function RVA.
- The table is complete enough to contain every command already measured as
working (
writeConfig,conDump,listCvars,exec,bind,toggle,screenshot). If one of those is missing, the enumeration is wrong - say so and fix it, do not ship a partial list as complete. - Explicit verdict on
map,devmap,spawn,teleport,god,noclip,killMonsters,reloadDecls,listCmdswith the evidence per name. - If a map command exists, decode its flag word against the flags of a command known to work and a command known to be rejected, and state exactly what makes the difference.
Verification expectations
Every important assurance needs a check that FAILS if the assurance is false:
- Positive control: the list must contain the commands measured as working.
- Negative control: feed the same parser a deliberately wrong base/section offset and show it produces garbage or refuses - a parser that "finds" a plausible table at the wrong offset is not evidence.
- Cross-check: the two attacks (data walk and call-site scan) must agree on the command set. Report the diff if they do not; the diff is the finding.
- The string "devmap" existing in .rdata is NOT evidence that the command is registered. docs/stand.md already lists it from static strings and the runtime contradicts it. Distinguish "string present" from "AddCommand called" from "dispatchable at runtime".
Failure honesty
If the registry layout does not yield, report the exact obstacle with offsets and what you tried. A clear negative with evidence is a good result here and unblocks the other two workers. Do not produce a speculative command list.
Coordination / deliverable
Checkpoint at meaningful milestones (registration function located; table walked; controls passed). Publish as bus facts only what the other workers would otherwise rediscover - above all the verdict on map/devmap, because it decides whether the save-forging route is necessary at all. Final report in German, concise, in re_probes/agent_reports/cmdtable.md. Finish the bus task when done; a master verifies.