A book becomes an adventure.
The player gets a say.

The project began with a practical constraint: I had jailbroken my e-reader and wanted to experiment with an interactive book without turning the device itself into the story engine.

That pushed the architecture toward a thin client. A device client should only need to display the current scene and choices, collect input and send HTTP/JSON requests. EPUB import and indexing, AI calls, story progression, validation and saved games belong on the server.

The browser and Node.js terminal clients already use that separation. A KOReader/Lua client is still a future device target, so this is an architectural direction rather than a claim that the current application is already an e-reader product.

A scene can read beautifully and still be wrong. A character might know something too early, act from the wrong perspective, or complete a decision before the player makes it.

The core problem is coordinating source material, player agency and persistent state. The engine needs to distinguish what has happened, what can happen now, and what still belongs to the future.

The original book provides a canonical route. It is a reference for progression, while the interactive timeline can diverge when the player makes a different choice.

The current implementation uses Node.js and TypeScript. A responsive browser client and a terminal client both talk to the same HTTP API. The clients present state and collect input; the server owns book analysis, AI orchestration, progression rules and persistence.

Local development uses file-backed repositories. The Azure configuration uses Blob Storage for analyzed books and Cosmos DB for user-scoped game saves. A Docker image and Bicep infrastructure support deployment to Azure Container Apps.

That boundary is what makes a small KOReader/Lua client feasible later: it can reuse the same server rather than duplicate the story engine on the e-reader. The repository already includes a Kindle-oriented data package, but the browser and Node clients are the current implemented interfaces.

The public snapshot was exported from the development code on 21 September 2026 and validated as a standalone repository. With Node.js 24.20.0 on Ubuntu, the TypeScript build passed and all 1,120 regular tests passed with 0 failures and 0 skipped tests. The same exported test suite also passed locally on Windows.

The tests cover source progression, player agency, validation, persistence, authentication, world rules, bridge logic and other deterministic behaviour. Separate Playwright tooling exercises the browser interface and repeated multi-turn flows.

Per-game logs record source progression, AI inputs and outputs, rejected generations and saved turns. These tools help reproduce failures such as premature dialogue suggestions, perspective drift and scenes that do not make the next action possible.

This remains an experimental AI application. Passing deterministic tests does not prove that every live model response, EPUB or sequence of player choices will behave correctly. Live-model evaluation and real e-reader testing remain separate concerns, and no aggregate reliability or latency benchmark is claimed here.

Amsterdam 750 explores a different set of constraints: high-demand registration and personal data protection. Its case study includes a public implementation and published load-test evidence.