steid

fix: the domain is jpgill.dev, not jpgilldev.com

I inferred the domain from an email address and never asked, so the wrong one
was baked into install.sh's RELEASE_BASE_URL, the systemd unit's Documentation
line, the runbook, and a doc comment explaining the apex redirect. The release
URL is the one that mattered: it is a constant inside a script that other people
download, so it had to be right before anything was ever served.

Found while checking DNS delegation rather than by reading anything — the .dev
registry reports jpgill.dev's nameservers as Google's, while the Route 53 zone
holding the A record is not delegated to, which is why the authoritative AWS
server answered correctly and every public resolver returned nothing.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01JZwc7URWKVhkAuRTWiDmjA

JamesPatrickGill authored 1 day agoparent59d0001Browse files7da29e07af9ccb7492205f7936b881c4c83848f1

6 files changed+10 −10

deploy/steid.service+1 −1View file

		@@ -12,7 +12,7 @@
12	12
13	13	[Unit]
14	14	Description=Steid
15		−Documentation=https://jpgilldev.com/jamesgill/repos/steid
	15	+Documentation=https://jpgill.dev/jamesgill/repos/steid
16	16	After=network-online.target
17	17	Wants=network-online.target
18	18

install.sh+1 −1View file

		@@ -45,7 +45,7 @@ set -eu
45	45	# profiles at /{handle}, so a root path would squat its own namespace. This is
46	46	# also exactly where a real release feature would put these files, so published
47	47	# links survive that feature landing.
48		−RELEASE_BASE_URL="${STEID_RELEASE_BASE_URL:-https://jpgilldev.com/jamesgill/repos/steid/releases}"
	48	+RELEASE_BASE_URL="${STEID_RELEASE_BASE_URL:-https://jpgill.dev/jamesgill/repos/steid/releases}"
49	49
50	50	# The version to install. Pinned rather than "latest" because there is no
51	51	# redirect to resolve "latest" against, and a pinned default makes the upgrade

plans/current.md+1 −1View file

		@@ -86,7 +86,7 @@ instance, and Steid's own source is pushed to it and browsable there.
86	86	deliberately says nothing about licensing rather than guessing.
87	87	- ~~Blocked on a domain transfer~~ — transferred 2026-08-29, so Phases 1–6 of the
88	88	deployment runbook are unblocked.
89		−- (historic) Blocked on a domain transfer (noted 2026-08-29). `jpgilldev.com` is the
	89	+- (historic) Blocked on a domain transfer (noted 2026-08-29). `jpgill.dev` is the
90	90	intended host for both the instance and the release downloads; the transfer is in
91	91	flight. Phases 1–6 of the deployment runbook cannot start until DNS resolves, because
92	92	Caddy requests a certificate on startup. Nothing else is blocked by it — the artifact

plans/runbook.md+4 −4View file

		@@ -252,7 +252,7 @@ hand-carried between repos.
252	252	## Deploying this instance
253	253
254	254	The operator's path, as opposed to `README.md`, which is written for a stranger
255		−installing their own. `jpgilldev.com` serves two roles from one box: this instance,
	255	+installing their own. `jpgill.dev` serves two roles from one box: this instance,
256	256	and the place everyone else downloads Steid from.
257	257
258	258	### Order matters
		@@ -281,7 +281,7 @@ and the place everyone else downloads Steid from.
281	281	fails at certificate issuance, not at first request.
282	282	- Snapshots are not backups. They are whole-disk and live in the same AWS account.
283	283	The two state paths still want copying somewhere else.
284		−2. DNS first, then install. `dig +short jpgilldev.com` must return the box's IP
	284	+2. DNS first, then install. `dig +short jpgill.dev` must return the box's IP
285	285	before `install.sh` runs. Caddy requests a certificate on startup; if DNS has not
286	286	propagated it fails and backs off, and the resulting error points nowhere useful.
287	287	3. First install uses `--tarball`. There is a bootstrap: this instance is what will
		@@ -289,11 +289,11 @@ and the place everyone else downloads Steid from.
289	289
290	290	```sh
291	291	scp dist/steid-0.1.0-x86_64-unknown-linux-gnu.tar.gz install.sh root@<ip>:/root/
292		−ssh root@<ip> './install.sh --domain jpgilldev.com \
	292	+ssh root@<ip> './install.sh --domain jpgill.dev \
293	293	--tarball ./steid-0.1.0-x86_64-unknown-linux-gnu.tar.gz'
294	294	```
295	295
296		−Then `curl https://jpgilldev.com/healthz` — over https, with a real certificate.
	296	+Then `curl https://jpgill.dev/healthz` — over https, with a real certificate.
297	297
298	298	### Becoming the distribution host
299	299

plans/ui.md+2 −2View file

		@@ -107,8 +107,8 @@ size last, and outside a page title, probably not at all.**
107	107
108	108	### The front door
109	109
110		−Steid is meant to be someone's site, reached at their own domain — `jpgilldev.com`, not
111		−`git.jpgilldev.com`, because a `git.` subdomain announces a Gitea clone and this is
	110	+Steid is meant to be someone's site, reached at their own domain — `jpgill.dev`, not
	111	+`git.jpgill.dev`, because a `git.` subdomain announces a Gitea clone and this is
112	112	portfolio-first. That makes the root a signpost rather than a page: unclaimed it sends
113	113	you to setup, and otherwise it forwards to a profile — your own when signed in, **the
114	114	owner's when not**.

src/application/claim.rs+1 −1View file

		@@ -23,7 +23,7 @@ pub async fn is_claimed(users: &impl UserRepository) -> Result<bool> {
23	23
24	24	/// The handle of the sole user, when this instance has exactly one.
25	25	///
26		−/// What makes a personal instance's front door work: `jpgilldev.com` should be the
	26	+/// What makes a personal instance's front door work: `jpgill.dev` should be the
27	27	/// owner's profile, not a sign-in prompt, and the root needs to know whose profile that
28	28	/// is without anyone being signed in.
29	29	///