The canonical catalog, in order, with current status. LIST GAMES recites every row EXCEPT tic-tac-toe: the film's scrolling list does not include it — David types it directly in the finale — so the slot is catalogued but never recited (2026-08-03 batch, pack#40):

tictactoe is the catalog's first slot with a second reconstruction (§8): beside the official core minimax sits heuristic by daniel, the rule-based player of the era — beatable by a fork, on purpose. LIST TIC-TAC-TOE at the terminal lists both; starting the title bare always runs core.

See contributing.md to claim a placeholder.

THE PROGRAMS ARE OPEN SOURCE

The games W.O.P.R. plays, the Joshua dialogue engine, and the systems you dial are open source in the public real-wopr-programs pack — each a self-contained program in a language of its era. Add or change one there and the exchange imports it; you do not need the engine.

CLAIM A GAME

The games — along with the Lisp Joshua and the dial-in systems — are open source in the public real-wopr-programs pack, each a self-contained program in a language of its era. That is where you add or change one; the hosting exchange imports it. You do not need the engine.

Only tic-tac-toe and Global Thermonuclear War appear in the film; every other entry in the catalog is a placeholder waiting for your interpretation.

1. Claim a placeholder (or propose a new game) by opening an issue on real-wopr-programs with its catalog id.
2. Add a self-contained Fortran program at games/<id>/main.f90 in the pack that speaks the WOPR/1 wire format — one request frame in, one response frame out. Copy an existing game as the template.
3. Add its harness/ beside it: a manifest.json (schema), a build.sh, and a tests/ directory of golden fixtures. In the manifest set status: implemented, an abbrev (the short tag shown in the prompt while your game holds the terminal, e.g. TTT), and "self_resolving": true if your engine resolves every non-human seat inside the human's MOVE. You do not declare which inputs are moves: the host attaches the terminal to your game and every line comes to you, so a new game routes with no engine change.
4. Golden fixtures are the test suite — request/response pairs that must reproduce byte-for-byte. No parsing logic needed; the protocol does the rest.
5. Follow the period-authenticity rules: period-plausible Fortran, deterministic given state+input, and a stated memory budget.

Because the host attaches the terminal to your game rather than inspecting what gets typed, a game is a self-contained, self-describing program: your contribution needs no changes to the engine — not the bridge, comms, surfaces, or database. The engine never has to learn your game's input grammar, because it never has to recognise it. See the pack's CONTRIBUTING.md and PACK.md for the full contract.

CONTEST A FEASIBILITY CLAIM

The feasibility analysis is meant to be argued with. If you lived through this era and a claim is wrong or imprecise:

1. Open an issue titled feasibility: <module> quoting the Claim and Confidence lines.
2. Provide your correction with a period source where possible (manual, spec sheet, first-hand experience, contemporaneous benchmark).
3. We update the module's Claim / What was achievable / What we approximate / Confidence block and credit the contributor in the doc.

Especially wanted: real 300-baud latencies and error rates, period Fortran compiler constraints, time-sharing session-state practices, IMS-vs-relational in defense circa 1982, and the true capabilities of NORAD/SAC display systems. Each module lists its open questions.

HOST AN EXCHANGE

Grow the phone book: run the stack on your own machine and claim a slot in one of the worlds. The hub is the switchboard — it lists your number while your carrier is up, and the slot opens again when you hang up. The host page generates the setup.