Archaeology of the project itself: three and a half days from copies of a folder and the history of git

The git history of the project Audamir is not complete. The first record is from 18 October 2026, 12:24 and has the message "first commit". By that time the game was already large. What happened before?

The archaeology of a project is the same work as the archaeology of anything: you have to find evidence that nobody intended to keep. In this case there are four pieces.

Evidence 1: the dates of files

The project folder was created on 17 October 2026 at 01:56. The first source files have the timestamp 03:50: the random number generator rng.js, the player colours palettes.js and the mosaics grid.js. At 04:00 the statistics were added, at 04:24 the AI, at 04:35 the game loop, at 05:25 the first calibration measurements, at 05:53 the rules and at 06:30 the tool for calibrating the score.

The date of the last modification of a file is not proof of when it was created (the file could have changed later), but for files that did not change afterwards it is fairly reliable.

Evidence 2: four copies of the folder

Next to the project there are four folders named dice-wars-1 (Copy) to (Copy 4). They are snapshots made during the day, before git existed. By comparing the lists of files and the sizes of the scripts you can tell what the game could do at which moment:

One thing is clear: the first playable version had in its README, as early as 17 October at six in the morning, a sentence saying that the Strong AI beats the Normal one in 73% of games. The measurement that a tool repeats today in three seconds was done in the first five hours.

Evidence 3: git from 18 October

From the first record the history exists and is fairly detailed: 200 records in all branches, of which 92 are from 18 October, 100 from 19 October and 8 from 20 October (by the morning of 20 October). There is one author of the records, and 195 of the 200 carry a co-author line (Co-Authored-By) with the name of the assistant. That is the answer to the question of how it is possible to build such a game in three days: with an assistant, and the history says so openly.

The rhythm of the work can be read in the history:

• Phases with documentation. Every bigger thing has not only code but also a part in docs/DESIGN.md, a tuning procedure in docs/TUNING.md, a line in README.md and a plan in docs/ROADMAP.md. The documentation of a phase tends to be near its end.
• Independent reviews. Eight records have "independent review" in the title and nineteen contain the word review. After each phase another agent reads the code, changes nothing and only reports. The next record tends to be "Fixes after the independent review".
• Branches by phases. The Avatar^[1] feature was built along the branches hero-dice-h1 to h4, the game record in the branch game-record, the languages in languages-cs-sr-ru. A branch corresponds to one phase or one chapter of the plan.
• Parallel work. On 18 October between 17:12 and 17:19 there were 26 records about converting the tests to English and about merging these conversions. Several agents worked simultaneously in separate working copies (worktree-agent-…) and the results were merged afterwards. In seven minutes dozens of files were converted this way.

Evidence 4: documentation as memory

The greatest evidence is the documentation. docs/DESIGN.md is 434 kB and is "the source of truth for later sessions", as its introduction says. The reason is practical: between sessions (chats) the assistant remembers nothing that is not written down. That is why in the project everything is written down: decisions with a date and a note of who decided (the author, or a proposal of the assistant approved by the author), measurements with the command by which they can be repeated, and what turned out to be a trap.

The plan of extensions (docs/ROADMAP.md) is written as an assignment for a new session. Each of the eighteen chapters is a separate task, and at the beginning stands an instruction on how to assign it: Read the ROADMAP, first the "Common rules", then chapter N. Propose a plan and open questions, and implement when we agree. It is a strange literary form: a document that is at once a plan, a command and a record of decisions.

In the "Common rules" there are eleven points from which one can read what has already broken in the project. For example: Ordinary games must not change. Everything that has a strength or a price is measured by games of AI opponents, not by estimate. Data from storage, backups and links are untrustworthy. Chance is derived from the state. Each of them is a scar from experience.

What can be derived from this, and what cannot

The numbers are impressive: in three and a half days almost 40,000 lines of scripts, 82 files with tests, 31 tools and 5,489 lines of documentation came into being. It is important, however, not to take them as an achievement in themselves.

• Lines of code are not the quality of the game. None of these numbers says whether the game is fun. That is decided by the people who play it, and so far there have been few of them. The author plays too, and some changes came only after playing (examples are the puzzles that seemed too easy, the article on puzzles (forthcoming article no. 10); the dice on the map were redone into round isometric ones after the first play).
• Speed moves the delay elsewhere. When code is written in hours, the delay becomes deciding and verifying: what should happen, what is right and whether it really happened. That is why there are so many measurements, tests and reviews.
• The time when a game is made in three days is new. Doom was made over thirteen months (November 1992 to December 1993) and Civilization cost, according to its author, about 170,000 dollars. A comparison makes no sense today: games are different and so are the tools. But it is one more reason why the article When the game was finished says that "finished" is a decision today.

One uncomfortable question remains: who is the author? The answer is that there are several authors and they are not equal. The decisions (what is built, what is thrown away, what is good enough) are mine and are written down with a date. The proposals, the code, the measurements and most of the text of the documentation are written by the assistant. The reviews are done by another agent. Whoever sees fraud in that has the right to another opinion. For whoever sees a new way of working in it, it is the theme of the whole series.

What I take from it

• Documentation is memory. In a project where work is done in separate sessions, what is written down is what happens.
• The rhythm of phases can be read. Whoever looks at the history sees where the turning point was, where the review was and where a phase ended.
• Numbers are not the game. A game is judged by playing it.

State of 31 October: what changed in eleven days

This article and the article on testing (forthcoming article no. 13) describe the state of 20 October. The same quantities eleven days later, on 31 October 2026:

The comparison should be read carefully. The size of the scripts was counted the same way as in the chart in the article (the sum of all .js files in js/), and most of the bytes today are the translation catalogues (nine languages), not the rules of the game. The most records were made on 30 October: 225; on that day, among other things, the tests and tools were merged in packages, the second board game Lines and the economy of the realms (docs/DESIGN.md §72 to §88). The documentation grew fastest: DESIGN.md grew more than fourfold, which matches the rule of this article that the assistant remembers only what is written down. The count of 956 is from the current repository, whose history was rewritten on 24 October (see above).

State of 1 November: one more day

The next day, 1 November 2026 (measured in the evening, dev in version 0.82.2):

Counts of records by day: 29 Oct 108, 30 Oct 225, 31 Oct 229, 1 Nov 144 (by the evening). The size of the scripts was counted the same way as above; most of the added bytes are the text catalogues in nine languages and the new steps of the home screen (articles 34 to 39). The difference in the count of records on 31 October (956 according to the entry above, 229 records on that day according to the dates) we cannot explain: the first number is from a single measurement during the day, the second from the whole day.

Sources and notes

• Dates and sizes: ls -l --time-style=full-iso and the sum of the sizes of the scripts in the copies dice-wars-1 (Copy) to (Copy 4) and in the working tree (20 Oct 2026). The copies are not in git.
• History: git log --all (200 records, 195 with the signature of a co-author, counts by day via --format=%ad).
• Doom and Civilization: the research for the article When the game was finished (Wikipedia, Kushner's book Masters of Doom; the costs are recollections of the authors).
• Decisions and rules of work: docs/DESIGN.md (the introduction, §13 and §21), docs/ROADMAP.md ("Common rules").
• State of 31 Oct 2026: git rev-list --count dev (956), git log --format=%ad --date=short | sort | uniq -c (counts by day), find js -name '*.js' -exec cat {} + | wc -c (6,544,506 B), find js -name '*.js' | wc -l (206), find tests -name '*.test.js' | wc -l (251), find tools -name '*.js' | wc -l (107), ls docs/*.md | wc -l (25), wc -c docs/DESIGN.md (1,815,102 B), node --test on the branch dev (3,314 tests; the run at the merge of 31 Oct 2026). The figures of 20 Oct are the original numbers of the article.
• State of 1 Nov 2026: the same commands as for 31 Oct (git rev-list --count dev 1,278, find js -name '*.js' | wc -l 310, find js -name '*.js' -exec cat {} + | wc -c 7,031,584 B, find tests -name '*.test.js' | wc -l 293, find tools -name '*.js' | wc -l 123, ls docs/*.md | wc -l 29, wc -c docs/DESIGN.md 2,306,419 B) and the last stamp node tools/verify.js --check 6cd1a86 (3,767 tests).