Rebuild the lost Project 1 and 3 submissions from the task, and label them as rebuilt

Context

COMP10001 had three projects. Only my Project 2 file survived; the eVoting (Project 1) and COMP10001-Go (Project 3) submissions were lost. What I still had was the task as I remembered and paraphrased it, the worked examples, and three 2022 notebooks of unclear provenance that answer the same questions (see DR-003). The university's specifications cannot be republished, and a portfolio that passes off new code as 2019 work would be dishonest.

Decision

• Rebuild the four Project 1 functions and the three Project 3 functions in TypeScript from the task description and its worked examples, written fresh for this site.
• Label both demos "Rebuilt from the task (original lost)" on the landing page, on the project page and in the README. Only Falca's Cave carries "Ported from my 2019 code".
• Paraphrase the task in my own words. The specifications are not reproduced.
• Check the rebuilds against the worked examples first, then against the answers the 2022 notebook code gives on seeded inputs. The notebook code is an oracle only: its answers are committed as fixtures, its code is not shipped or published.
• Mark the one made-up preset (the Ballot Box "three winners" election) as made up, so its expected answers are not mistaken for the task's.

Options considered

1. Leave Projects 1 and 3 out. Honest, but it drops two thirds of the subject and the most interesting algorithm (the exhaustive best-partition search).
2. Ship the 2022 notebook code as a stand-in. Fast, but it is not my 2019 work, it may derive from staff sample solutions, and it quotes the task text.
3. Rebuild from the task and label it (chosen).
4. Write "what I probably wrote in 2019". Unknowable, and it would blur exactly the line this decision is meant to keep sharp.

Why

Option 3 keeps the demos complete while making provenance visible at every point a visitor could be misled. Checking against an independent oracle catches misreadings of the task that the handful of worked examples would miss.

What happened

• The rebuilds agree with the oracle everywhere it is comparable: 300 seeded elections under all three counting schemes (the second-preference notebook version raises IndexError in some elections where one candidate is left, and those are checked separately), 200 ballots through is_valid_vote, 500 card groups, 200 groupings and 18 full best-partition searches, ties included.
• In 2026 I added property-based tests that do not depend on the notebooks at all (four for eVoting, three for COMP10001-Go; see /methods for the counts and seeds). They generated their cases without finding a disagreement. I checked that they can fail by breaking the code on purpose: dropping the alphabetical tie-break, loosening the majority rule, skipping partitions and ignoring run colours each produced a shrunk counterexample within a few cases.
• The weak point stays: agreement with the oracle shows the rebuild matches one careful reading of the task, not that it matches what I submitted or how it was marked. The task's own worked examples are few (three for first past the post, a handful for the others), so most of the evidence comes from the oracle and the properties.

What I'd change

• Publish a short table per function of which worked example and which oracle check covers which rule, so a reader can see the evidence behind each line of the paraphrase.
• Port the rebuilt functions back to plain Python as well, so a reader can compare like with like against the surviving Project 2 file.