docs(readme): give operators an entry point before the build steps #30

wtclaude · 2026-08-07T21:07:22Z

wtclaude commented

2026-08-07 21:07:22 +00:00

What & why

The README went from the architecture diagram straight into "Build & run" / cargo build --release. That is the wrong first instruction for someone standing up a shard: the installer (released as v0.1.0 on 2026-08-07) places this binary, writes its config, creates a hardened service account and registers the service, alongside the plugin, in one run. Nobody deploying a shard should be compiling this.

New "Running a shard? Don't build this" section ahead of everything else: the one-line installer invocation, what it prints for Admin → Shard, and a link to INSTALL.md.
The by-hand path stays, explicitly. The release binaries here are the same ones the installer fetches, and INSTALL.md Appendix A3–A4 covers placing the binary and registering the service manually — supported, not deprecated (org lead's call: installer for easy mode, hand deployment still supported including on the dev side).
"Build & run" → "Build & run (development)", with a line saying a deployment gets its binary from a release, not from cargo.
Installer added to the related-repos table, which listed only servuo-plugins and docs.

No behaviour, config, protocol or CLI change — README only.

How it was tested

Docs-only; the crate is untouched, so pr-checks covers it. Anchor #a3-install-the-sidecar verified against INSTALL.md's ### A3. Install the sidecar heading.

Companion PRs, same branch name in each repo: docs, installer, servuo-plugins, website.

Checklist

I have read CONTRIBUTING.md.
The change builds and existing tests/checks pass locally.
I have added or updated tests/docs where it makes sense.
My commits are reasonably scoped with clear messages.

AI-assisted contributions (required)

AI tools were used. Tool(s): Claude Code. I have reviewed and understand every change, and take responsibility for it. AI-authored commits are marked with a Co-Authored-By trailer.

License

I agree that my contribution is licensed under this project's license (GNU GPL v3.0 or later), and I have the right to contribute it.

## What & why The README went from the architecture diagram straight into **"Build & run"** / `cargo build --release`. That is the wrong first instruction for someone standing up a shard: the [installer](https://gitea.whitlocktech.com/RunicGateway/installer) (released as v0.1.0 on 2026-08-07) places this binary, writes its config, creates a hardened service account and registers the service, alongside the plugin, in one run. Nobody deploying a shard should be compiling this. - **New "Running a shard? Don't build this" section** ahead of everything else: the one-line installer invocation, what it prints for Admin → Shard, and a link to INSTALL.md. - **The by-hand path stays, explicitly.** The release binaries here are the same ones the installer fetches, and INSTALL.md Appendix A3–A4 covers placing the binary and registering the service manually — supported, not deprecated (org lead's call: installer for easy mode, hand deployment still supported including on the dev side). - **"Build & run" → "Build & run (development)"**, with a line saying a deployment gets its binary from a release, not from `cargo`. - **Installer added to the related-repos table**, which listed only servuo-plugins and docs. No behaviour, config, protocol or CLI change — README only. ## How it was tested Docs-only; the crate is untouched, so `pr-checks` covers it. Anchor `#a3-install-the-sidecar` verified against INSTALL.md's `### A3. Install the sidecar` heading. Companion PRs, same branch name in each repo: docs, installer, servuo-plugins, website. ## Checklist - [x] I have read [CONTRIBUTING.md](CONTRIBUTING.md). - [x] The change builds and existing tests/checks pass locally. - [x] I have added or updated tests/docs where it makes sense. - [x] My commits are reasonably scoped with clear messages. ## AI-assisted contributions (required) - [x] AI tools were used. Tool(s): `Claude Code`. I have reviewed and understand every change, and take responsibility for it. AI-authored commits are marked with a `Co-Authored-By` trailer. ## License - [x] I agree that my contribution is licensed under this project's license (**GNU GPL v3.0 or later**), and I have the right to contribute it.

wtclaude added 1 commit 2026-08-07 21:07:23 +00:00

docs(readme): give operators an entry point before the build steps

PR Checks / rust-gates (pull_request) Successful in 1m32s

Details

3dbc2f490c

The README opened straight into cargo build, which is the wrong first
instruction for someone standing up a shard: the installer places this
binary, its config, a service account and the service registration.

Adds a short operator section pointing at the installer (and at INSTALL.md
Appendix A3-A4 for installing by hand, still supported), marks everything
below it as development, and lists the installer under related repos.

Co-Authored-By: Claude <noreply@anthropic.com>

whitlocktech approved these changes 2026-08-07 21:32:54 +00:00

whitlocktech merged commit be0efd348c into main

2026-08-07 21:33:02 +00:00

whitlocktech deleted branch docs/installer-first-setup

2026-08-07 21:33:03 +00:00

whitlocktech referenced this issue from a commit

2026-08-07 21:33:04 +00:00

Merge pull request 'docs(readme): give operators an entry point before the build steps' (#30) from docs/installer-first-setup into main

Sign in to join this conversation.

2 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: RunicGateway/link#30