Keep my 2019 cave code exactly as submitted, with a separate spec-correct mode

Context

My Project 2 file (coursework/project-2-toy-world/grok_project_2.py) survived. It printed the expected 23 and 14 on the two sample caves, which is all I checked in 2019. Replaying it on hundreds of caves shows real bugs: the dragon guards only its own square instead of the eight around it as well, shortest_path returns 1 for the same square, optimal_path arms Falca before she reaches the sword, gives up early when there is no treasure and crashes with IndexError when nothing is reachable. A revived demo could hide these or show them.

Decision

• "As submitted (2019)" is the default mode. It is a faithful TypeScript port that must reproduce the Python's answer on every seeded cave, including the inputs where the Python raises an exception; the UI shows those crashes instead of masking them.
• "Spec-correct" keeps the same search strategies (level-by-level breadth-first search, uniform-cost search over the points of interest) and fixes only the listed bugs.
• The page lists each quirk in plain words, and presets show where the two modes disagree.
• The 2019 file itself stays byte-identical under coursework/, and CI checks it still prints 23 and 14.

Options considered

1. Port only the original. Faithful, but visitors would see wrong answers with no way to tell which are wrong.
2. Fix the bugs and present the result as my 2019 code. Misrepresents the past.
3. Fixed by default, original hidden behind a toggle. Better, but the default view would still not be what I submitted.
4. Both modes, the original first (chosen).

Why

The original is the artefact; the fixes are commentary on it. Defaulting to the 2019 code and labelling the fixed version as a separate mode keeps the record straight and turns the bugs into something a visitor can explore.

What happened

• The 2019 parity suite replays my unmodified Python on 230 seeded caves (2 samples, 8 hand-made, 220 random) through all four functions, crashes included, and the port matches every answer. The spec mode matches the 2022 notebook oracle on the same caves, apart from one intended difference: the notebook's build_cave accepts four treasures and the task allows three.
• In 2026 I added three property-based tests for the searches. Spec-correct shortest_path equals an exhaustive enumeration of simple paths; spec-correct optimal_path is never beaten by any enumerated order of waypoints, equals the cheapest one and equals a breadth-first search over (square, sword, treasures), and the route it draws passes check_path in exactly that many moves. A third property pins down what the 2019 bug means: my 2019 shortest_path is never longer than the spec answer, never misses a route the spec finds, and agrees exactly once Falca holds the sword.
• Breaking the spec mode's dragon rule on purpose made the first two properties fail within a handful of generated caves, which is the evidence that they would catch a regression.

What I'd change

• Let fast-check search for the smallest caves where the two modes disagree, and use those shrunk examples as the presets, instead of my hand-picked ones.
• Show a side-by-side diff of the 2019 Python and the spec-correct TypeScript for each fix.