1. Decide what you want to build
++ Open with a practical question: do you want to understand a game, + rebuild it, move it to another platform, or change how it plays? +
+-
+
- + Reconstruction: recover source and check it + against the original program. + +
- + Port: make that source work with a new + platform’s rendering, input, audio and files. + +
- + Mod: understand a behavior, change it + deliberately, then test the result. + +
+ Planned figure: one recovered codebase branches into a faithful + build, a port and a mod. Each branch names its own success check. +
+2. Turn expertise into a repeatable process
++ The industrial-age analogy: agents do the work, tools let them + inspect the program, checks test the result, and the repository + preserves what they learned. +
+-
+
- + Make the task small enough to check. One + behavior or connected subsystem has a clear input, output and + test. + +
- + Make feedback fast. A compile error, mismatch + or runtime failure tells the agent what to investigate next. + +
- + Make experience reusable. A lesson becomes a + script, test, evidence note or handoff that survives the + conversation. + +
+ Standardize the checks and the handoff; leave the investigation + flexible. + REA fits at the inspection step: it gives the agent code, + references and observations. Source reconstruction and project + validation complete the loop. +
+3. TH08: continue the work people already did
++ Start with the public GensokyoClub reconstruction: its code, + names, build knowledge and contribution history. Show how a + continuation turns that foundation into an explicit baseline and a + sequence of checked tasks. +
+-
+
- + Preserve credit and inspect what the inherited source actually + establishes. + +
- + Record the target, existing checks, missing source and next + useful work. + +
- + Use the path to Linux and Web to introduce the value of + readable, maintained source. + +
-
+
- + Independent continuation begins. + +
- + Source recorded for all 1,107 identified game + functions. + +
- + Playable Linux port committed, about 11 days after the + continuation began. + +
- + Native Linux 64-bit release published. + +
+ Lesson: a good workflow makes existing expertise + easier to extend. The starting foundation remains part of the + result. +
++ TH08 repository · + History and credits +
+4. TH095: start a new game with an established method
++ The new repository starts with zero confirmed authored functions. + It already has experience from earlier reconstructions: target + checks, task boundaries, comparison tooling and a way to retain + evidence. +
+-
+
- + Bring up the build and comparison loop early, then work through + bounded tasks. + +
- + Use the timeline to show what “fast” means for source recovery, + exact comparisons and a playable build. + +
- + Explain one integration failure in plain language: individually + correct functions can still use the wrong shared state when + assembled into a program. + +
-
+
- + Repository initialized; authored source count starts at + zero. + +
- + 697 / 697 identified game functions have source, about 9 days + later. + +
- + 696 / 697 identified game functions accepted as exact. + +
- + Windows i386 reconstruction marked playable, about 12 days + after initialization. + +
+ Lesson: the next game starts with more than a + prompt. It starts with a working process and the previous game’s + lessons. +
+ +5. TH04: keep the method, rethink the assumptions
++ PC-98 changes the practical problem. The game spans four DOS + programs and depends on older hardware behavior. Existing ReC98 + work supplies valuable knowledge; the new reconstruction still + needs its own checks. +
+-
+
- + Map the whole product: startup, menus, gameplay, endings and the + resident component. + +
- + Show why one excellent function percentage can leave important + parts of the game untested. + +
- + Adapt the comparison and runtime checks to the platform. Feed + discoveries back into reusable tests. + +
-
+
- + Reconstruction repository bootstrapped. + +
- + 661 / 663 reviewed game functions accepted across four + programs. + +
- + Four standalone DOS products built, about 26 days after + bootstrap. + +
+ Lesson: reuse the process, then verify the + assumptions that the new platform changes. +
+ +6. Run small experiments and keep useful checkpoints
++ Bring the three stories together into a working loop a reader can + use. +
+-
+
- + Establish a baseline. Identify the exact target + and rerun the checks that matter to this task. + +
- + Pick one question. Choose a behavior or + subsystem with a result you can inspect. + +
- + Gather evidence. Follow the code that reads or + changes a value, and the functions that call it; name what is + known and what still needs testing. + +
- + Reconstruct and check. Compare the affected + code, build the program, and exercise relevant behavior. + +
- + Commit and hand off. Keep source, evidence, + failed hypotheses and the next task in the repository. + +
+ Explain how this loop continues across fresh agent sessions. Turn + a recurring failure into a test so the next game benefits from it. +
++ Planned figure: a failing experiment returns to investigation; an + accepted batch feeds both the next task and the shared knowledge + base. +
+7. Use the recovered source for ports and mods
++ Explain the payoff: source with meaningful names, clear ownership + and reproducible checks is something you can change with + confidence. +
+-
+
- + Use TH08’s Linux and Web products to illustrate replacing + platform services while preserving game logic. + +
- + Show how a small mod begins with one recovered rule and a + controlled change. + +
- + Connect the desired outcome to its checks: faithful behavior, a + working new platform, or an intentional gameplay difference. + +
+ Planned figure: checked reconstruction → readable source → + portable backend or a deliberate gameplay change. +
+8. Start with one behavior you can verify
++ Close with a small first task, an example agent prompt, and what + the reader should keep: recovered source, a reproducible check and + a clear next question. +
++ The article’s final prompt will walk through one bounded + reconstruction batch. The + native analysis guide and + setup guide cover the tools + needed to begin. +
+Sources and timeline counting
++ Dates above come from public GitHub commits and releases, + checked on 10 October 2026. Elapsed days are calendar time + between recorded checkpoints. Each row names its milestone: + source presence, function comparison, build or runtime. +
+-
+
- + Touhou Reconstruction Factory: project memory, bounded work, empirical feedback and + cross-game lessons. + +
- + TH08 continuation start, + source checkpoint, + Linux port + and + 64-bit release. + +
- + TH095 initial ledger, + source checkpoint + and + exact comparison checkpoint. + +
- + TH04 bootstrap, + four-artifact ledger + and + four-product build checkpoint. + +