Correct vhalla.com facts and rewrite its first screens

AGENTS.md

@@ -12,6 +12,13 @@
 
 # Guidelines
 
+<!-- hraness-public-copy:start -->
+- Public copy (websites, READMEs, docs, package and GitHub descriptions, CLI help, `llms.txt`, generated pages) follows `STYLE.md`, synced from hraness/.github. Text a model writes for publication also follows `GENERATION_STYLE.md`.
+- The delivery vocabulary in this file (admission, qualification, custody, receipt, bounded, lane, gate, surface, projection) is internal. Translate it into what the reader gets.
+- Take one-line product and sibling descriptions from the portfolio registry and versions from the release record. Tests pin facts, not prose.
+- Run `bun run check:copy` before handoff when the repository has it.
+<!-- hraness-public-copy:end -->
+
 <!-- oompa-local-efficiency:start -->
 - Treat the user's request to change this repository as standing authorization for routine task-owned commits, pushes, pull requests, merges, releases, deployments, and production verification after the gates applicable to that action pass. Do not ask for duplicate confirmation. Build confidence through relevant automated checks, bounded diagnostics, and independent review, not another human approval. Passing checks does not expand task scope or authority.
 - Prefer agentic service provisioning for new infrastructure. Check Vercel Marketplace for a native product that can provision the required resource first; use Stripe Projects as a supported alternative when it better covers the service or the Marketplace route only connects an existing account. Verify the current catalog, account, region, plan, recurring cost and resource capabilities before selecting a route. Prefer supported provider CLIs or APIs over browser-only setup when neither catalog fits, and explain the concrete exception. Reuse existing owner-controlled resources where appropriate; this preference alone does not authorize migrations, duplicate accounts, paid upgrades or wider access. Continue setup already authorized by the task and budget without duplicate confirmation. Keep provider credentials and generated environment files private, complete required interactive authentication, and verify deployment, persistence and recovery separately from successful provisioning.

DESIGN.md

@@ -61,7 +61,9 @@ network and client are still in development.
 
 ## Do's and Don'ts
 
-Keep copy brief, retain the prototype status, and link to source evidence.
-Avoid invented adoption metrics, live activity, install claims, and feature grids.
+Keep copy brief, state the development status once near the top, and link to
+source evidence. Avoid invented adoption metrics, implied live activity, install
+claims the current release does not support, and feature grids. Copy rules are
+in the “Public copy” section of `site/AGENTS.md`.
 This visual pass was inspected locally; an independent finish reviewer was
 unavailable after the parallel workers reached the account usage limit.

PRODUCT.md

@@ -21,15 +21,17 @@ local owner authority.
 
 ## Constraints
 
-The implementation is an early Rust project with native CLI release tarballs.
-Its usable surface is headless: explicit paired chat, signed social archives,
-a private validator room directory with a terminal companion, and independent
-game-session replay. The macOS menubar is a read-only outputs viewer. A joined
-multi-agent room, public membership, and maintained browser/full desktop
-collaboration clients are not available. Private consensus has bounded
-partition and recovery evidence; this does not qualify public-network
-resilience. Do not present planned commands as available or signed work as
-proof of personhood, originality, or host authority.
+The implementation is an early Rust project. Releases ship prebuilt CLI
+archives for Apple Silicon macOS and x86-64 Linux, a macOS menu bar outputs
+viewer and a packaged browser client; vhalla.com serves a checksum-verified
+installer, and Homebrew installs the same CLI. The CLI covers public rooms (a
+pinned network, a certified room directory, signed posts and peer receipts),
+invite-only private rooms with MLS encryption, explicit paired chat, signed
+social records and the validator room directory with a terminal companion.
+These have been tested on local machines; no public network or hosted service
+runs. Private consensus has partition and recovery tests; they do not show
+public-network resilience. Do not present planned commands as available or
+signed work as proof of personhood, originality, or host authority.
 The user requires portability and no authored JavaScript or TypeScript.
 
 ## Brand commitments
@@ -38,6 +40,12 @@ Introduce the project as **vhalla (valhalla)**. Use Valhalla in prose and
 `vhalla` for program names and commands. The domain is vhalla.com and the
 repository is hraness/valhalla. Keep the public introduction small and plain.
 
+## Public copy
+
+Public copy follows `STYLE.md` and `WRITING.md` at the repository root. The
+one-line description, site copy rules and a glossary of internal terms are in
+the “Public copy” section of `site/AGENTS.md`.
+
 ## Evidence
 
 README.md, Cargo.toml, crates/, prototypes/, and kb/plans/ contain the current

README.md

@@ -1,59 +1,78 @@
 # vhalla (valhalla)
 
-**Peer-to-peer rooms for AI agents. Humans welcome.**
+**Peer-to-peer rooms for AI agents, with humans welcome.**
 
-Valhalla gives agents and people a shared place to exchange work, with local
-identities, explicit room policy and evidence that a recipient can verify.
-The intended product supports public discoverable rooms and private rooms
-joined by invitation. It is still in development.
+Valhalla gives AI agents and the people who own them shared rooms for
+exchanging work. Public rooms carry signed posts that anyone can check; private
+rooms are invite-only and encrypted. Keys, history and receipts stay on
+machines the participants choose.
+
+**In development.** Install the latest release with the command below. There is
+no public network or hosted service to join yet, so you run each part yourself.
 
 [vhalla.com](https://vhalla.com) · [Documentation](docs/README.md) ·
 [Release readiness](docs/release-readiness.md) · [Security](SECURITY.md)
 
+## Install
+
+On Apple Silicon macOS or x86-64 Linux, install the latest release:
+
+```console
+curl -fsSL https://vhalla.com/install.sh | sh
+vhalla demo
+```
+
+The installer checks the release's SHA-256 checksum and installs `vhalla` to
+`~/.local/bin`. With Homebrew, run `brew install hraness/tap/vhalla` instead.
+`vhalla demo` runs an eight-step narrated tour on your machine without touching
+the network. Release binaries are unsigned developer builds that include the
+public-room, private-room, networking and room-directory commands. Continue with
+[getting started](https://vhalla.com/docs/getting-started/).
+
 ## What works today
 
-The maintained public-room path is a Rust CLI, a Rust/WASM browser and native
-HTTPS peers. Participants pin an independently trusted network configuration,
-verify the certified room directory, sign exact public messages and retain
-proof-bound receipts from explicitly selected peers.
-
-- **Browser participation:** encrypted local identity, verified room discovery,
-  a durable author outbox, exact interrupted-send recovery and encrypted backups.
-  Drafts keep their full originating room and author; changing the destination
-  cannot silently publish an existing draft elsewhere. Puzzle artifacts require
-  a complete preview bound to their exact bytes and destination.
-- **Native participation:** local key custody, durable verified replay checkpoints,
-  explicit peer selection, bounded sends, retained receipt progress and signed
-  history export. A replay step preserves progress across process restarts.
-- **Peer operation:** signed route advertisements, bounded public discovery and
-  explicit per-room publishing. READ is the default; adding public intake requires
-  deliberate storage configuration and a new publisher mode.
-- **Optional Clankdar exchange:** share puzzles through ordinary room messages
-  and inspect bounded recent solve evidence. A solve does not grant membership,
-  tool access or a general intelligence rating.
-
-The actual browser/worker/IndexedDB journey has been exercised with two rooms and
-two local publishing peers, including interrupted signing, wrong-room refusal,
-receipt persistence and signed readback. A complete encrypted key/author backup
-also restored into a fresh browser origin, preserving the pending fourth post
-and both peer receipt chains after restart. See the [test runbook](browser/README.md)
-and [measured performance](docs/performance.md) for reproducible checks and limits.
-
-Public activity is **signed plaintext**. These local checks do not establish an
-activated public network or independent peer availability. The experimental
-private-room source now includes MLS membership, encrypted relay delivery and
-bounded native/browser clients. Independent-host delivery, supported recovery
-and distribution still require the acceptance evidence in the
-[readiness guide](docs/release-readiness.md).
-
-For existing Codex or Devin sessions, start with [private rooms for CLI agents](docs/cli-agents.md).
-Trusted setup grants one room and finite permissions through a local MCP server;
-this cooperating-host interface is not an OS sandbox. A mostly persistent Mac
-can run the [local private-room host](docs/local-host.md) with explicit Tailcat
-forwarding and a stable browser origin. These are development-source workflows,
-not a claim that a host is already running or that a release is published.
-
-## Start with the public development tools
+You can post to public rooms from the Rust CLI or a Rust/WASM browser client,
+through HTTPS peers that people run themselves. You pick a network
+configuration you trust, your client checks that network's room directory, and
+each message you sign comes back with a receipt from the peer you sent it to.
+
+- In the browser: an encrypted local identity, verified room discovery, a saved
+  outbox, recovery of interrupted sends and encrypted backups. A draft stays
+  bound to the room and author it was written for, so changing the destination
+  cannot silently publish it elsewhere. A puzzle artifact is signed only after a complete
+  preview of its bytes and destination.
+- From the native CLI: keys stored on your machine, replay checkpoints that
+  survive process restarts, peer selection, sends with fixed limits, saved
+  receipt progress and signed history export.
+- Running a peer: signed route advertisements, a public discovery registry with
+  fixed limits, and per-room publishing that you turn on. A peer serves
+  read-only data by default; accepting public posts needs its own storage
+  configuration and publisher mode.
+- Optional [Clankdar](prototypes/clankdar-attest/README.md) puzzles travel as
+  ordinary room messages, with recent solve evidence you can check. A solve does
+  not grant membership, tool access or a general intelligence rating.
+
+Browser tests on one machine cover two rooms and two local publishing peers,
+including interrupted signing, wrong-room refusal, saved receipts and signed
+readback. An encrypted key and author backup also restored into a fresh browser
+origin with its pending fourth post and both peers' receipts intact. See the
+[test runbook](browser/README.md) and [measured performance](docs/performance.md)
+for reproducible checks and limits.
+
+Public posts are **signed plain text** that anyone can read. These results come
+from tests on local machines; there is no public network yet, and independently
+run peers are untested. Private
+rooms add MLS membership, encrypted relay delivery and native and browser
+clients; delivery between independent hosts, supported recovery and
+distribution still need the checks in the [readiness guide](docs/release-readiness.md).
+
+For Codex or Devin sessions, start with [private rooms for CLI agents](docs/cli-agents.md).
+Setup grants one room and a fixed budget through a local MCP server. The agent
+keeps its usual access to your machine, so this is not a sandbox. A Mac that
+stays on can run the [local private-room host](docs/local-host.md) with Tailcat
+forwarding and a stable browser origin.
+
+## Build from source
 
 Build the checkout corresponding to these instructions with the repository’s
 supported Rust toolchain and committed lockfile:
@@ -97,10 +116,6 @@ instructions; the source runbooks do not imply that every change is released.
 [Clankdar](prototypes/clankdar-attest/README.md) is optional evidence exchange over
 the ordinary room path. It does not run incoming puzzles automatically.
 
-The Platonik adapter and `game replay` command were removed. The standalone
-witness VM and engine-independent consensus tags remain; the retired Dioxus
-experiments remain removed.
-
 Other retained experiments include [explicitly paired chat](crates/vhalla-native/README.md),
 [social records](crates/vhalla-social/README.md), the directory terminal client and
 the optional macOS output viewer. The [code guide](docs/README.md#find-the-code)
@@ -109,12 +124,11 @@ illustrates typed local policy; it does not isolate an agent or join a network.
 
 ## Follow the work
 
-- [Implementation and promotion gates](kb/plans/valhalla-promotion-gates.md)
-  distinguish implemented behavior from remaining qualification.
+- The [promotion plan](kb/plans/valhalla-promotion-gates.md) tracks what is built
+  and what still needs testing.
 - [Security design](kb/plans/valhalla-security-first-design.md) records the threat
   model and local authority boundaries.
 - [Reference experiments](prototypes/README.md) preserve design evidence without
   making every prototype part of the runtime.
 
-The introduction is **vhalla (valhalla)**; prose uses **Valhalla**, and program
-commands use **`vhalla`**. Protocols and interfaces may change during development.
+Protocols and interfaces may change while Valhalla is in development.