Install one-liner first: README top + xerj.org hero + llms.txt - #219

User directive (2026-08-08): the simple one-liner install becomes the MAIN
thing a visitor sees on both the README and the xerj.org landing page.

Both endpoints were verified live before writing any copy:
  curl -fsSL https://xerj.org/get      -> POSIX sh installer: resolves the
    latest GitHub release (v1.0.0-rc.12 at time of writing, XERJ_VERSION to
    pin), sha256-verified fail-closed, installs a single static binary to
    ~/.local/bin (or XERJ_INSTALL_DIR / cwd fallback), does NOT edit PATH --
    it prints the path and an export hint; next steps printed:
    'xerj --insecure --data-dir ./data' + the console URL.
  curl -fsSL https://xerj.org/get.ps1  -> PowerShell installer: same
    resolution + sha256, installs to %LOCALAPPDATA%\Programs\xerj and adds
    it to the user PATH (XERJ_NO_PATH=1 opts out) and the current session.

README.md -- reordered, nothing deleted:
  old: H1+intro / ES-API para / badges / video / Install / Index a folder / ...
  new: H1+intro / Install (sh + PowerShell) / one-line first-commands pointer
       (server then autoindex, linking #index-a-folder) / badges / video /
       Index a folder / ... (all remaining sections unchanged)
  The ES-API sentence moved into the install block's follow-on paragraph.

landing/index.html + style.css -- the hero now leads with the install
command: a large copyable command block (site visual language kept: 1px
accent left rule, mono type, text-only COPY affordances, no icons/fills),
the Windows variant beneath it, and -- per XERJ's AI-first positioning --
an adjacent paste-to-your-agent one-liner. The naive form
'curl ... | sh && xerj autoindex .' is NOT honest (the sh installer does
not touch PATH, and autoindex is a client of a running node at
localhost:9200 -- verified in engine/crates/xerj-autoindex/src/cli.rs:122
and esclient.rs: ensure_index is single-attempt, so a boot race is real).
The shipped line is the honest three-step: install -> start
'xerj --insecure --data-dir ./data' -> 'xerj autoindex .', query :9200.
Copy handler added to the existing inline script; style.css?v bumped
(additive classes only, other pages unaffected). Rendered and checked in
both day and night themes at 1600x1080 via puppeteer.

landing/llms.txt -- new '## Install (start here)' section directly after
the intro: both one-liners, verified installer facts (targets, sha256,
install dirs, PATH behavior), and the ordered first-run sequence
(server -> autoindex -> query), with the client-of-a-running-node caveat
stated. The AI-native positioning section is preserved unchanged and still
precedes everything else that classifies the project.

Landing build note: landing/ is a plain static Cloudflare Pages site
(wrangler.toml pages_build_output_dir = "landing", no build step; the
functions/ dir is Pages Functions). Nothing was deployed.

The adversarial review of the install-first restructure (PR #219) verified the
pages against the live installers and found two honesty defects:

- The hero label and llms.txt claimed unconditional fail-closed SHA-256
  verification, but the sh installer skips verification with a warning when the
  machine has neither sha256sum nor shasum (get lines 95-102). The label now
  says SHA-256 CHECKSUMS and llms.txt states the exact behaviour.
- README's first-commands line assumed xerj is on PATH (the sh installer does
  not edit PATH) and hid a real boot window: autoindex run immediately after
  backgrounding the server exits 1 with 'endpoint unreachable' (reproduced with
  the rc.12 binary, ~2-6s to ready). The line now carries the PATH pointer and
  a wait-until-:9200-responds step.