The build is the assembled book: one file made from all the chapters in the order of the table of contents, and from it a web page and a PDF. It is built by a script, not by a human and not by a model. The tools are maintained by the tools programmer (PRO), in the same session also the production manager: a model that does not write prose. The chapter shows where the builder takes its data from, what runs where, and how an editorial decision becomes a line in a file.
The builder reads the first line of the table of contents, the only place where the version number appears in the book's files, and the table with the order of the chapters. It does not change the chapters. The day counter under the title (the clock), the white pages with a subheading (the divider pages) and the positions of the photos are kept in separate files and can be changed without touching the program. The PDF file has the version, the date and the time of generation in its name; corrections are never made in it, only in the chapters. The second builder reads the same table of contents and records every chapter in three text-to-speech voices: narration, the hero, the machine.
All the sessions meet in one place: in the repository's single branch, that is, the directory of files with the full history of changes. The roles of the cycle, that is, the models that write and check the text, work in the cloud and do not see the raw data, that is, the export of the conversations and the original photos. Those stay on the author's computer together with the build, which the assistant's local session runs there; the PDF is made there by printing from the browser. Three things go outside: text to the text-to-speech service, the file built in “review” mode to NotebookLM, in which two model-generated voices talk about the book, and the PDF for the printing firm. This last line is dashed: the requirements of three printing firms are written down, the trim size is 6 × 9 inches (earlier A5), and no record of the file being sent to print was found in the repository.
In Part II a counter of days to Kasia's answer appears under the chapter title. The build calculates it from dates. A chapter that ends before day zero gets the number of days; one that ends on day zero, the caption “Day zero”; every later one the date alone. The two dates and the wording of the counter are three lines of one file (“chodnik” is the pavement, “etykieta” the label):
chodnik: 2025-01-03
zero: 2026-07-14
etykieta: to Kasia's answerPart I counts the days to the first date, Part II to the second. The reason for the rule is given in the commit subject, that is, the subject of an entry in the history of the repository. A mini-turn is a short piece of work by a role outside the queue; R-9 is the number of a proposal by the lead editor, and the label was changed that same evening to the one in the file.
2026-10-04 18:18 COMMIT: [PRO] mini-turn: fix R-9 – Part II clock “days to her answer”, after day zero the date alone (the clock does not give away the ending); label and dates in RUCHY.md
2026-10-05 10:11 COMMIT: [PRO] ksiazka.py --jezyk en: English edition from przeklad/en/ (headings, clock, build captions, Tell-Me-Yes-vX.Yen); Polish output unchanged
On the same day, 5 October, four files of version 3.52 came out of one table of contents: Polish and English, each with photos and without. They differ only in the options of one command. The builder has more of them: mode (preview, print, review), photo resolution, photo layout (full or one of four variants), three styles, two accent colours, two kinds of captions under the photos. The English file is five pages longer in both variants.