Three finished worlds are code studies, not a local generator
fable51-worlds contains three main Fable 5.1 outputs: Union Square in San Francisco, Higashiyama in Kyoto, and a playable Death Star trench run. Each has its own runtime, source tree, media, controls, and research or build notes. Parallel GPT-6 Astra versions provide recorded side-by-side comparisons. The top-level claim that a prompt becomes a world describes how the artifacts were produced. The repository does not include the Claude Fable 5.1 service, an orchestration command, or a reusable prompt-to-world pipeline that a new user can run.
That distinction makes the project easier to judge fairly. As finished examples, the worlds are ambitious and specific. Union Square uses mapped buildings and storefront work. Kyoto turns surveyed route and elevation data into a continuously walkable district. The Death Star project builds its craft, trench, effects, shaders, flight, enemies, camera direction, and procedural audio from code. Its README documents a 3-minute 12-second cinematic, a 21 km playable trench, 30 camera shots, and deterministic QA controls exposed through window.__demo.
The 393.8 MB checkout behaves like an archive of separate projects
Our clone contained 739 files, about 75,992 lines of source, and 393.8 MB before installation. Much of the repository's value is visible without building: comparison videos, preview GIFs, stills, prompts, contracts, and final QA reports sit beside the code. That makes it useful for reading and visual inspection. It also means cloning the repository to study one world brings several distinct Fable and Astra implementations plus their media. There is no top-level package or shared runtime that normalizes their setup.
The measured project lives in death-star-trench-run/. Its package file defines dev, build, preview, typecheck, and QA commands, but declares no dependencies or development dependencies. There is no lockfile in that folder. The TypeScript configuration expects Vite client types, and the Vite configuration imports Vite, while the source relies on Three.js. Those requirements are visible in code but absent from the install manifest. A reader can infer what is missing; a package manager cannot.
What happened when we ran it
Our sandbox ran npm install in the Death Star subproject. It finished in 1 second, installed 0 packages, and left 37 MB on disk. The build then exited with code 127 after 1 second. Its command was tsc --noEmit && vite build, and the shell stopped at tsc with sh: 1: tsc: not found. The log establishes an undeclared or unavailable compiler, without showing whether the source would pass once the toolchain is supplied.
No test script or target existed, so the lab skipped tests. Npm audit reported 0 known vulnerabilities, split as 0 critical, 0 high, 0 moderate, and 0 low. That empty result needs context: the install added 0 packages. The repository also had 0 CI workflow files, no Dockerfile, and no tests directory. Its world-specific QA scripts may perform useful checks, but our clean environment could not reach them through a declared, installed toolchain.
The QA notes are stronger than the install manifest
The Death Star README records defects that visual review caught after the code ran without console errors. White emissive surfaces washed out a scene, speed differences left enemy fighters kilometres behind, smoothing displaced wingmen and cameras, and an unloaded trench exposed a hole through the station. The project also documents remaining flaws in the explosion and shockwave. These notes are valuable because browser graphics can be logically valid while looking plainly wrong, and they show why screenshots, fixed viewpoints, and a complete timed sequence matter.
The claimed last verification reached 12 of 12 phases and 30 of 30 shots, with steering, boost, lasers, and trench ceiling checks. Those are project-authored results from its README, not measurements from our sandbox. We could not reproduce them after the 0-package install. The right lesson is still useful: contracts between agent-built modules and separate visual reviewers can catch integration faults that source review misses. The repository preserves those contracts and defect reports well enough to study even when its packaging falls short.
Two location worlds still have a documented data-ingress gap
The top README says every stage can be rerun. Open pull request 3 says the Union Square GIS builder reads a raw file excluded by .gitignore, while Kyoto names its map snapshot and roughly 200 elevation queries without providing a fetch step. The contribution proposes manifests, adapters, provenance, and CI to close that gap. Until it is merged and connected, the public claim is ahead of what a clean clone can regenerate for those worlds.
Licensing also needs project-level attention. Code and generated assets use MIT, OpenStreetMap-derived geometry carries ODbL obligations, and public elevation sources have their own provenance. The location projects use real business names for identification. The Death Star entry is an unaffiliated homage and explicitly leaves Lucasfilm trademarks with their owner. A learner can read and modify the work; a commercial reuse decision needs a narrower asset and attribution review than the repository-level MIT badge suggests.
Nine September days show interest, not established maintenance
The repository was created on September 2, 2026 and last pushed on September 9. GitHub showed 514 stars and 4 combined open issues and pull requests, with activity continuing through September 13. No GitHub release exists. Three of those open items are pull requests, including the reproducibility work and another submitted world. That is encouraging outside engagement for a young project, but there is too little history to infer a stable release process or long-term acceptance of contributions.
fable51-worlds earns a bookmark for its procedural rendering decisions, agent contracts, and honest visual postmortems. The lab result changes the adoption advice: 0 installed packages, a missing compiler, and no test target make it a reference collection today. Copy a technique after tracing its dependencies and license, or repair one subproject's manifest before experimenting. Teams seeking a foundation should start from Three.js, Babylon.js, or PlayCanvas and treat these worlds as worked examples rather than infrastructure.

