Suppose the reviews service is renamed to booknest-ratings and then shelved. Renaming keeps everything and leaves redirects behind; archiving freezes the repository read-only, so its code stays visible without implying that anyone maintains it:
gh repo rename booknest-ratings -R binarybehemoth/booknest-reviews --yes
git -C booknest-reviews ls-remote origin HEAD | cut -f1
gh api repos/binarybehemoth/booknest-reviews --jq .full_name
gh repo archive binarybehemoth/booknest-ratings --yes
gh repo view binarybehemoth/booknest-ratings --json isArchived,url
git -C booknest-reviews push --dry-run origin HEAD:refs/heads/test✓ Renamed repository binarybehemoth/booknest-ratings
458cbc949ea7051d946df7b8b294d9a056173387
binarybehemoth/booknest-ratings
✓ Archived repository binarybehemoth/booknest-ratings
{"isArchived":true,"url":"https://github.com/binarybehemoth/booknest-ratings"}
remote: This repository was archived so it is read-only.
fatal: unable to access 'https://github.com/binarybehemoth/booknest-reviews.git/': ...The clone's origin still names booknest-reviews, and both Git 1,932 and the API follow the redirect. Only a GitHub Pages 29 project site and workflows using an action from the renamed repository break. Never reuse the old name, or the redirect stops. Archiving makes code, issues, pull requests, labels, releases and permissions read-only (the push above got a 403); gh 29 repo unarchive reverses it.
Transferring moves a repository to another owner, typically from a personal account into an organization (not run here, since this account has no organization): Settings, Danger Zone, Transfer, or gh api repos/binarybehemoth/booknest/transfer -f new_owner=booknest-org. Issues, pull requests, stars, webhooks and secrets travel with it and old URLs redirect; a transfer to another person waits for their emailed acceptance.