iili: rename the shortener from r3dr, and answer HEAD (#1359, #1433)

[aaylward]

The shortener is called iili everywhere now: domains/iili/apis/iili, the iili compose service and ghcr.io/muchq/iili image, the iili OTEL service name, the moonbase.iili smithy namespace, and the public paths /iili/v1/shorten and /iili/v1/r/{slug}.

Folds in the two things left parked: #1433, and the go.mod prune deferred from #1434.

The wire moves with no alias

/r3dr/v2/* stops answering the moment the host takes this. Both frontends have to move with it, which makes the order load-bearing:

0. Change the iili Workers project's Root directory to /domains/iili/apps/iili_web. The app moved and that setting lives in the Cloudflare dashboard, not this repo, so its build fails until it is changed — see the comment below. This has to come first, or iili.uk keeps serving the pre-rename bundle.
1. Merge this. Cloudflare deploys iili_web, which now calls /iili/v1 — minting on iili.uk is down until step 2. Redirects keep working (the old Caddy still rewrites onto the old path, and the old container still serves it).
2. Full deploy.sh on the host, promptly. API and Caddy flip together, so iili.uk recovers and i.iili.uk/r/{slug} never has a gap. muchq.com/iili is now down.
3. Merge iili: follow the API rename off /r3dr/v2 muchq.github.io#279, which is the companion for this. Cloudflare deploys it and muchq.com recovers.

deploy.sh verifies images exist before touching the host, so step 2 has to wait for publish.yml to build ghcr.io/muchq/iili on main. A rollback to any commit before this one will be rejected for that service, as it is for any service younger than the target.

The database keeps the old name

The Postgres role and database stay r3dr_v2, and R3DR_V2_DB_PASSWORD stays the ~/.env secret — renaming a role and database holding the live rows is an operation with a cutover, not a rename of this repo. iili_db_init provisions them under the old names, the container-facing URL var becomes IILI_DB_URL, and the mismatch is stated in compose.yaml, the deploy README and the service README rather than left to be discovered.

HEAD (#1433)

HEAD /r3dr/v2/r/{slug} returned 405: smithy-cpp's router buckets by exact method (routes_.find(request.method)) and only GET was registered, so unfurlers and link checkers leading with HEAD never saw the Location. WithHeadAsGet answers HEAD from the GET routes and clears the body — content on a HEAD response desynchronizes a keep-alive connection. main.cc and both test harnesses share the one composition, so the wire test exercises what production runs.

Two wire tests pin it. Mutation-checked by removing the shim from the harness: HeadGetsTheSameRedirectAsGetWithNoBody fails with Which is: 405 — the exact defect the issue describes.

One guard instead of two

TestNoDeployConfigNamesR3dr replaces both TestR3drNetCaddySitesAreGone and TestNoDeployConfigNamesTheGoR3drStack: after the rename the only legitimate r3dr in the deploy surface is the database identifier, so the rule is "no r3dr except that", which subsumes the old host check and the Go-stack token list.

Worth flagging on the test it replaces: that token list carried an r3dr_v2 → V2 rewrite I described in #1434 as keeping the replacement service from tripping the tokens. It never did — no line in any scanned file would have tripped one without it. The exemption is load-bearing in the new rule, where it protects the database identifier, and that is checked rather than asserted.

Also

• hashicorp/golang-lru/v2 and lib/pq leave go.mod, go.sum and the gazelle use_repo list — the Go service that imported them retired in r3dr: retire the Go service and its serving stack (#1359 chunk 3) #1434, and nothing else in the repo does.
• .gitignore drops go/r3dr/deploy/deploy.sh, a path from a layout that no longer exists.

Verified

bazel test //domains/iili/... //deploy/... //domains/platform/apis/prom_proxy/... //bazel/rules:rules_test — 23 targets green. iili_web: 39 tests, typecheck clean. scripts/format-all clean. The build caught one real break the greps could not: smithy_handler.h included a smithy/http/http.h that does not exist (RequestHandler lives in smithy/http/transport.h).

After deploy

Metrics continuity breaks by design: the OTEL service name changes, so history stays under service_name="r3dr_v2" while the dashboard tiles now query iili. The panels will look empty until new data accumulates; the old series are still in Prometheus under the old name.

Also worth clearing once the deploy lands: a stale R3DR_V2_SHA= line in the host's ~/.env, if a targeted deploy ever wrote one. The pin-clearing loop only iterates variables the current compose.yaml reads, and it now reads IILI_SHA.

🤖 Generated with Claude Code

https://claude.ai/code/session_01ST7XLGWstRE4CfUF84ijKD

[cloudflare-workers-and-pages]

Deploying with    Cloudflare Workers

The latest updates on your project. Learn more about integrating Git with Workers.

Status	Name	Latest Commit	Preview URL	Updated (UTC)
✅ Deployment successful! View logs	1d4-web	8bbf03a	Commit Preview URL Branch Preview URL	Aug 22 2026, 06:10 PM

[cloudflare-workers-and-pages]

Deploying with    Cloudflare Workers

The latest updates on your project. Learn more about integrating Git with Workers.

Status	Name	Latest Commit	Updated (UTC)
❌ Deployment failed View logs	iili	8bbf03a	Aug 22 2026, 11:52 PM

[aaylward]

Blocker, and it needs a dashboard change — I can't fix this one from the repo.

Workers Builds: iili failed on 946c0d4. Every GitHub Actions check is green, including test-iili-web, and Workers Builds: 1d4-web succeeded on the same commit.

The cause is the directory move. That Cloudflare project's Root directory is /domains/r3dr/apps/iili_web, and this PR moves the app to /domains/iili/apps/iili_web. Nothing in this repo sets it — per iili_web/README.md the build command, deploy command and root directory are all configured in the Workers dashboard, so the rename can't carry it. 1d4-web is the control: same build, path untouched, green.

The fix is one field on the iili Workers project:

• Root directory: /domains/iili/apps/iili_web (was /domains/r3dr/apps/iili_web)
• Build command and deploy command are unchanged — the app folder is still iili_web, only its parent moved, so dist/iili_web/wrangler.json still resolves.

This moves ahead of the merge in the order. The production build fails the same way a PR build does, so merging first would leave iili.uk serving the previous bundle — the one calling /r3dr/v2 — and that path stops answering as soon as the host takes the rename. Minting on iili.uk would then stay broken until the setting is changed, rather than for the short window the PR describes. Changing it before merge costs only some failing builds on branches still based on the current main.

---

Generated by Claude Code

[aaylward]

Two retries of Workers Builds: iili on 8bbf03a just failed the same way. A retry alone can't clear this — it re-runs against the same Root directory, and that is the thing that's wrong.

Ruling the repo out as a cause: I ran the dashboard's exact commands from the new location, /domains/iili/apps/iili_web — npm ci && npm run build succeeds and produces dist/iili_web/wrangler.json, which is precisely what the deploy command (npx wrangler deploy --config dist/iili_web/wrangler.json) expects. Nothing in the app or its config needs changing.

So the build stays red until the iili Workers project's Root directory is changed from /domains/r3dr/apps/iili_web to /domains/iili/apps/iili_web. Build and deploy commands stay as they are.

---

Generated by Claude Code