PLAN.md §5.4. The status section still announced Phase 1 as built and
Phase 2 as next, four phases later -- it is the first thing a visitor to
this repo reads, and it has been wrong since Phase 2 merged.
- The phase table now shows 1-4 built on `edge` and 5 in progress, and
the opening says what the binary actually does.
- "What the cutover is waiting on" is stated, because "nothing is
released yet" invites the question: Phase 5, and the Windows SCM half
never having been executed anywhere.
- "Planned commands" is now "Commands". All four are implemented.
- RUNICGATEWAY_STATE_DIR was described as relocating install.json. Since
Phase 2 it relocates everything the installer writes, including the
sidecar binary, and suppresses service registration -- an out-of-date
description of where a tool writes is worse than none.
- A design-constraint bullet for the backup behaviour Phase 5 adds.
Co-Authored-By: Claude <noreply@anthropic.com>
Adds the Rust crate at the repo root and implements `install` end to end for
the overlay half of a deployment: resolve the published bundle, find and
validate the ServUO root, refuse to deploy under a running shard, sync the
plugin overlay, and record what was deployed in install.json.
`doctor`, `update` and `uninstall` parse and answer with the phase they arrive
in rather than "unrecognized command", and the run states plainly that the
uo-link sidecar (Phase 2) and the patch tier (Phase 3) were not installed —
`--patches` in particular reports REQUESTED BUT NOT APPLIED, since a quiet
completion would be read as a patched shard.
Landing on `edge` rather than `main`: release.yml publishes a binary on every
push to main, and an installer that deploys the overlay but cannot install the
sidecar is not something to hand an operator. pr-checks.yml now gates PRs into
edge on the same rules, so the branch the work happens on is not the ungated
one.
Notable decisions, all documented in docs/installer/PLAN.md §5 Phase 1:
- The code lives in a library called `rgdeploy` with a thin binary that keeps
the published name. Windows' UAC installer detection refuses to launch an
unsigned executable whose file name contains "install" (os error 740), and
Cargo names test harnesses after their target — so a target under that name
makes `cargo test` unrunnable on Windows.
- The running-shard check matches processes by path, not by process name:
on Linux a live shard is `mono`/`dotnet` with ServUO.exe as an argument, and
a name match would report "not running" for a shard that is running.
- install.json records a state (`deployed` / `kept-operator-modified`), not the
run's verb, so an unchanged re-run produces an identical record and writes
nothing.
- The Bridge.cfg keep rule compares against the hash the installer last
deployed, not the last hash it saw — otherwise a kept file is overwritten on
the very next run.
- Downloads are verified against the bundle's SHA256 while being written, then
every extracted file is re-hashed against the release's own manifest.json,
whose protocol and version are cross-checked against the bundle.
Verified against a real ServUO 57.4 tree and end to end into a scratch tree:
24 files deployed, an unchanged re-run that writes nothing, an edited
Bridge.cfg kept across repeated runs while code files are overwritten, bundle
pinning, and a refusal with a shard running out of the tree.
Co-Authored-By: Claude <noreply@anthropic.com>
Phase 0 item 3 of docs/installer/PLAN.md (§7.1-§7.3). The installer resolves
what to install *from* the bundle, so this has to exist before Phase 1 code is
useful. Both components it composes now have releases, which is what unblocked
it.
Adds .gitea/workflows/bundle.yml — resolve both components' latest releases,
run the two compose-time gates, and publish bundles/current.json — plus the
first real bundle (2026.08.04: link v1.1.0 + overlay v0.1.1, protocol 3).
Bundles are COMMITTED under bundles/, not published as releases. This repo's own
releases are the installer binaries, and /releases/latest returns whichever
release is newest regardless of kind, so interleaving bundle releases would make
"latest" intermittently resolve to a release carrying no installer binary. The
push to main needs no new branch-protection exception: release.yml's version-bump
commit already requires it.
Gate 1 (protocol agreement) reads the sidecar's PROTOCOL_VERSION from
sidecar/src/main.rs at the release tag, not from the binary. --print-config
would answer, but only for releases from v1.1.0 on, and --bundle <tag> has to be
able to recompose an older bundle. It also avoids executing a downloaded
artifact and provisioning a throwaway config whose auth token would land in a CI
log. The overlay half comes from manifest.json inside the tarball, which is the
only statement of that version that exists.
Gate 2 (assets) downloads every asset and verifies it against the SHA256SUMS its
publishing repo shipped, then records the hash it computed itself. These
artifacts are deliberately unsigned, so a hash copied from a file nobody checked
would make the whole chain decorative. An asset with no SHA256SUMS entry is
caught separately, since `sha256sum -c` passes right over it.
Release reads are ANONYMOUS on purpose: they are exactly the requests the shipped
installer makes on a host with no Gitea credentials, so a repo flipped to private
fails here rather than on an operator's machine.
Stale components (§7.3) are dispatched, never awaited — Gitea's dispatch endpoint
returns no run handle. "Ahead of its release" counts only releasable commits and
excludes merge commits, whose subject quotes the feat/fix title and would
otherwise re-dispatch a workflow that correctly declines to run, every night.
A run that finds nothing changed writes nothing, comparing everything except
`bundle` and `generated` — that is what makes the nightly cron free rather than a
dated duplicate every morning.
Verified by running the workflow's exact compose steps in a Linux container
against the live releases: both gates pass, the composed bundle is the file
committed here, a re-run reports changed=false, and the stale-detection filter
scores 1 releasable commit for link v1.0.0..main (excluding the merge that quotes
it) and 0 for a docs-only range.
Co-Authored-By: Claude <noreply@anthropic.com>
The installer repo was created empty. Seed it with the same governance set
every other Runic Gateway repo carries, so it starts on the same footing
before any Rust code lands (see docs/installer/PLAN.md for the design of
record — this repo is still in the planning phase).
Copied verbatim, byte-identical to the other repos:
LICENSE.md (GPL-3.0-or-later), CODE_OF_CONDUCT.md, CONTRIBUTORS.md,
.gitea/PULL_REQUEST_TEMPLATE.md, .gitea/ISSUE_TEMPLATE/{bug_report,
feature_request}.md
Repo-specific:
README.md what the installer is, what it deliberately is not
(no curl|bash, never writes a ServUO launcher), the
planned commands, and the constraints a reader needs
up front: unsigned releases, bundle-manifest
composition, opt-in patch tier, and the fact that a
successful copy is not a working bridge.
CONTRIBUTING.md adapted from link/ (same Rust toolchain and checks),
plus a planning-status note pointing changes of scope
at the plan in docs/, and the two shard-testing traps.
SECURITY.md adds the installer to the component scope table and a
short subsection on its distinct trust model: unsigned
releases anchored on SHA256SUMS, mandatory
verification of downloaded artifacts, and the
never-contacts-the-website token handoff. This is the
only file that now differs from the other repos' copies.
.gitignore Rust build output plus local deployment state
(install.json, sidecar.toml, *.db) that must never be
committed from a test run.
.gitea/ISSUE_TEMPLATE/config.yaml same as elsewhere, repo-local URL.
No CI workflows yet — there is no crate for pr-checks to build, and the
release/bundle workflows are Phase 0 work that depends on servuo-plugins
gaining a release workflow first.
Co-Authored-By: Claude <noreply@anthropic.com>
