Read the flight code through its original page references
Open Luminary099/MAIN.agc and you get a reading route through the lunar module's software: landing guidance, restart handling, and the executive all point back to printed pages. Apollo-11 preserves the command module's Comanche055 and lunar module's Luminary099 as searchable text. That's useful when you want to follow a particular decision through the actual program instead of settling for a retelling of the mission. Luminary's source index makes that route explicit.
Our checkout occupied 3.7 MB across 262 files, so keeping a local reading copy is easy. The main README is English, with translations linked alongside it. You can browse the assembly on GitHub without starting a service. A local editor helps with searching and comparing passages, though the contribution guide recommends AGC syntax extensions because ordinary editor support isn't enough. Reading is accessible. Understanding a routine still means learning its machine and conventions.
What happened when we ran it
Our sandbox installed Apollo-11's repository tooling in 10 seconds, adding 39 packages and occupying 7 MB on disk. We cloned commit 911e5c0 on October 11, 2026, into a fresh Debian container with 3 CPUs and 8 GB of RAM, using the lab-node:22 image and Bun. The container had no secrets or elevated privileges. The install succeeded, which establishes that this tooling path worked under those conditions.
The build and test steps were skipped because the repository supplied neither a build target nor a test target. Our scan found 2 CI workflow files, no Dockerfile, and no tests directory. Those results don't certify the flight software's assembly or behavior. A dependency installation can finish cleanly while leaving the historical program completely unexecuted. That's the boundary of this run, and it matters more than the short installation time.
Bun installs Markdown tooling, while compilation lives elsewhere
The inspected package.json defines Markdown lint commands and uses markdownlint-cli2 for development. This explains why a repository of AGC assembly shows up in a Node-oriented lab run. There is no web application to launch through those commands. The README's compilation section sends you to Virtual AGC, and its attribution names yaYUL as the assembler. The package manifest describes the tooling we installed.
Don't make the 39-package result your estimate for an emulation setup. It covers this repository's tooling only. Reading the files needs no API credential, model download, or hosted account, but assembling and executing them requires the separate AGC toolchain and its instructions. I'd start with Virtual AGC if interactive execution is the objective. Apollo-11 is the smaller choice when you mainly need the listings and their links to the paper originals.
Contributions must preserve errors printed in the original
Apollo-11's contribution rules explicitly require comments to match the scanned printouts. That includes restoring a historical misspelling when the transcription accidentally corrected it. The guide also specifies tab formatting and how to handle blank lines. This is a preservation policy with practical consequences: a well-meant spelling cleanup can make the archive less accurate. Compare the relevant scan before proposing a change. The proofing instructions explain what counts as a correction.
The 262-file checkout is convenient for searching, but searchable text shouldn't be treated as unquestionable evidence. Pull request 1002 proposes comment corrections in Comanche's RT8 interpreter file after comparison with the original listing. Its author limits the claim to those comments and explicitly avoids claiming assembler certification. That's a sensible model for readers too: verify the passage your argument depends on rather than assuming the surrounding archive has received the same scrutiny. That RT8 proofing proposal remains open.
A July push and October proofing activity tell different stories
The last push was July 15, 2026, while the issue and pull request feed contained fresh proofing proposals on October 11. GitHub reported 73,939 stars and 146 open issues and PRs when checked. The latest-release endpoint returned no published release. Together, those facts show an archive attracting continued contributions without proving that the new corrections have landed. Star count is evidence of attention, not a measure of transcription accuracy or reviewer capacity.
The 2 workflow files likewise deserve a narrow reading. The inspected Markdown workflow checks documentation formatting, and our lab skipped application tests because no target was provided. For this archive, maintenance means preserving and checking listings. I wouldn't penalize it for lacking a stream of product releases, but I also wouldn't give it the assurance score of a tested modern library. A recent proofing proposal can be useful evidence even while its corrections await acceptance.
Virtual AGC is the closer choice for execution
Virtual AGC supplies the surrounding AGC software and emulation tools that Apollo-11's compilation section points toward. Its current repository is virtualagc/virtualagc, despite the older owner link in Apollo-11's README. Choose it when you want to assemble code or interact with an emulated computer. NASA's GMAT is an adjacent alternative for present-day mission design and navigation analysis, rather than a substitute archive of these flight programs. Virtual AGC's project explains its broader scope.
Keep the 3.7 MB archive when your question is specific: how does this listing handle a restart, or what does its executive do when work is suspended? The page references let you check the answer against the original material. For a lesson, article, or historical investigation, that traceability earns Apollo-11 a place on your disk. Before quoting a comment as evidence, open its scan and check that the transcription says what the paper says.