Holonovel MCP server

<!-- README DESIGN:

Product principle. The README answers three questions for three readers, each in under 60 seconds: an operator gets a running server, an evaluator understands what it does and how it differs, a contributor finds how to help. It is a design document, not an afterthought. Every section earns its place.

Scannability. Engineers scan, don't read. Consistent heading hierarchy (ATX only, no setext). No wall of prose — every section is broken into digestible paragraphs. One story vector per section.

Voice. Punchy, reserved, grounded in fact. Direct address ("you"). No first-person ("we", "I", "our"). Professional without being cold. No "obvious to me" assumptions — every sentence survives a reader who knows nothing about the project.

Plain English (Standing Rule 10). Describe what the user does, not what the tool is called. Write as if instructing a person, not documenting an API. Tool names, parameter shapes, and technical syntax SHALL NOT appear in prose. The validator enforces this.

Structure. Orientation → Table of contents → Run a server (§1) → How it works (§2) → How it compares (§3) → Contribute (§4) → Footer. No other ordering. Section headings use canonical numbering (§1–§4) matching the TOC and cross-reference links. The TOC is a bulleted list of every h2 and h3 heading with Markdown anchor links, each h2 entry tagged by audience. It does not link to itself or the Orientation.

Audience split. §1 is for operators who want a server now — one copy-paste quick-start sequence, plus installing and building rulesets. §2 describes capabilities to an evaluator. §3 is the competitive landscape — one row per competitor category. §4 is for contributors.

Orientation. Exactly four elements: h1 heading, bold tagline on its own line, the MCP server card badges (below the tagline), one prose paragraph (≤80 words). The paragraph defines "holonovel" as a Star Trek holodeck program. States what Holonovel builds (the server, the Holodeck), what a campaign becomes (the program, the Novel), and what rulebooks become (the engine). Names D&D 5e and Starfinder as example rulesets the spec can build. Closes with "Your books. Your server. Your Holodeck."

Table of contents. Bulleted list of every h2 and h3 heading with Markdown anchor links. Appears between the Orientation and §1. Each h2 entry carries a trailing audience tag — operators, evaluators, or contributors — outside the link. h3 entries are untagged. No prose, no descriptions. The validator enforces TOC-to-heading consistency.

Run a server (§1). Three h3 subsections. No introductory prose under the h2. Install: one descriptive sentence, prerequisite (Node.js 20+), shell code block for install, and copy-paste JSON config block with placeholder. Install a ruleset: drop-in packages, lazy loading, and the .holonovel-state/ location. Build your own rulebook: the build-ruleset entry point. Config blocks use json language tag. Shell blocks use sh. No blockquotes, no tool names in prose.

How it works (§2). One introductory h2 sentence (≤50 words) naming the pipeline, then five stages — Convert → Build → World → Novel → Synthesis. Each stage follows this format:

self-contained sentence valid on the holonovel MCP server.

1. What-it-is paragraph — defines the capability conceptually.
2. What-you-can-do paragraph — describes player/GM capabilities.
3. Demo blockquote — 2–5 natural-language prompts, each a

Badge enforcement is not a stage — it is a cross-cutting runtime layer, described once inside Novel. No forward references between stages. Each stage is readable independently.

1. Closing takeaway — one factual sentence, not a slogan.

Shortened. The full README is on GitHub.