Repository Transfer Preflight Inventory and Risk Register

Owner: todo/00-infrastructure/TODO-09-repository-transfer-rizonetech.md §1. Baseline captured: 2026-04-27 (commit-time snapshot; re-baseline immediately before pressing the transfer button per §4). Purpose: every observable surface that must be re-checked after the move from rizonesoft/impossible-os to rizonetech/impossible-os is captured here once so §5/§7 can compare directly instead of remembering. Move-back to a personal account (§8) re-uses the same shape.

This document is observation only. It does not change Pages, DNS, or any GitHub setting. Edits that ship configuration belong in §2-§9 of the TODO.

1. Repository Identity

Local remotes (git remote -v):

origin      https://github.com/rizonesoft/impossible-os.git              (fetch + push)
bootloader  https://github.com/rizonesoft/impossible-os-bootloader.git   (fetch + push)

The bootloader remote is a separate repository (rizonesoft/impossible-os-bootloader) and is OUT OF SCOPE for this TODO. TODO-09 transfers impossible-os only; whether the bootloader repo follows is a later decision.

2. GitHub Pages State

Two findings flagged for §3 / §5:

1. Pages source mismatch with TODO-09 introductory callout. The TODO's Current state says "GitHub Pages is deployed by .github/workflows/pages.yml". In reality, the API reports build_type: legacy from the gh-pages branch -- the live site is whatever was last pushed to refs/heads/gh-pages (sha 35e7dcd5, 2026-04-12). The workflow IS configured but its last run failed. §3 must decide whether to switch the source to "GitHub Actions" cleanly during/after the transfer or keep the legacy branch source. Until then, both must keep working.
2. HTTPS enforcement is OFF. Cert is approved and the apex serves on HTTPS, but https_enforced: false means the default redirect from https://rizonesoft.github.io/impossible-os/ lands on http://impossibleos.co/ (plain HTTP), which then upgrades. This is a hardening gap that should be fixed in §5 under the new owner.

Pages workflow failure root cause: Failed to CreateArtifact: Artifact storage quota has been hit. for the rizonesoft user account. Transfer to the rizonetech enterprise org will get a new artifact storage budget, which paradoxically may fix this. Worth verifying in §7 by re-running the workflow after transfer.

3. Live Domain Baseline (curl + DNS)

Captured 2026-04-27 ~19:54 UTC.

HTTP HEAD

DNS

TTL inspection: dig is not installed on this host (/bin/bash: line 3: dig: command not found). Operators must run dig +nocmd impossibleos.co A and dig +nocmd www.impossibleos.co CNAME from a host with BIND tools (or nslookup -debug) immediately before transfer to capture the authoritative TTL. §3 already plans to drop the www CNAME TTL pre-transfer; the apex A-record TTL also needs the snapshot for the §7 "TTL is restored to normal value after transfer window" check.

Apex HTTPS certificate: the GitHub-managed cert covers BOTH impossibleos.co and www.impossibleos.co, expires 2026-06-16. Transfer must complete and the new owner's Pages settings must accept the custom domain BEFORE that expiry, otherwise GitHub may not auto-renew.

4. GitHub Actions State

Active workflows (gh workflow list --all):

The TODO's Inputs list names five workflows; the actual count is seven repo-defined workflows plus the auto-generated pages-build-deployment. §6 must include todo-graph.yml and visual-regression.yml in the URL/badge sweep if either references the old owner.

Workflows that reference the old owner explicitly: must be checked file-by-file in §6 (this preflight does not edit). The fast scan to run during §6:

rg -n 'rizonesoft' .github/workflows/

Pre-transfer concurrency note: all current workflows are triggered on push to main or on workflow_dispatch. None depend on owner-scoped GitHub Apps or marketplace-restricted actions. The actions/* family used by pages.yml (checkout / configure-pages / upload-pages-artifact / deploy-pages) is universally available; under the rizonetech enterprise plan, no allowlist needs adjustment.

5. Repository Settings That Do Not Reliably Travel

Items GitHub may or may not bring across cleanly during a transfer; verify directly under the new owner.

Branch protection / rulesets

§5 (TODO) must reapply this ruleset under the new owner if GitHub does not migrate it. The required-status-check context: "Build Impossible OS" matches the Build workflow's job name; check that the job name has not changed during transfer.

Secrets and variables

BOOTLOADER_REPO_TOKEN is the single critical secret; the release workflow consumes it. Validate post-transfer by running the release workflow on a no-op tag. If GitHub fails to migrate the secret value (it usually preserves the name but not always the value), regenerate the token and re-push it.

Environments

Webhooks, deploy keys, integrations

§5 should turn Dependabot alerts on under the new owner -- this is a free hardening for a freestanding-kernel repo even though dependency surface is small.

Releases / packages

6. Access Model

Org-level baseline for the receiving side (rizonetech):

§2 (TODO) is the section that confirms org Actions / Pages / Copilot policy parity before pressing the transfer button.

7. Hard-Coded Owner References (Inventory)

Captured by rg -n 'rizonesoft/impossible-os|github\.com/rizonesoft|rizonesoft\.github\.io|hits\.sh/rizonesoft' README.md CONTRIBUTING.md SECURITY.md CODE_OF_CONDUCT.md AGENTS.md CLAUDE.md docs gh-pages .github todo scripts -- the path set was expanded to include todo/ and scripts/ after the initial pass missed scripts/todo-graph/render.py:42 (REPO_URL_BASE = "https://github.com/rizonesoft/impossible-os/blob/main"), the actual generator constant for TODO graph links. Re-runs of this baseline MUST use this expanded path set, not the narrower one.

Two snapshots are tracked because this preflight doc itself is a source of references:

Per-pattern breakdown (post-doc expanded baseline):

Files containing at least one match (39 in post-doc expanded baseline; the originally-scanned 28 narrow-path files plus docs/infrastructure/repository-transfer-preflight.md, 8 files under todo/ and 2 files under scripts/):

README.md                                 docs/index.md
CONTRIBUTING.md                           docs/getting-started/virtualbox.md
docs/infrastructure/github-setup.md       docs/infrastructure/development-tooling.md
docs/infrastructure/ai-system.md          docs/infrastructure/todo-graph.md
docs/boot/boot-protocol-changelog.md      docs/infrastructure/repository-transfer-preflight.md
.github/ISSUE_TEMPLATE/feature-request.yml .github/ISSUE_TEMPLATE/config.yml
gh-pages/index.html                       gh-pages/err/index.html
gh-pages/err/errors.js                    gh-pages/err/0000/index.html
gh-pages/err/0001/index.html              gh-pages/err/0002/index.html
gh-pages/err/0003/index.html              gh-pages/err/0004/index.html
gh-pages/err/0005/index.html              gh-pages/err/0006/index.html
gh-pages/err/0007/index.html              gh-pages/err/0008/index.html
gh-pages/err/0009/index.html              gh-pages/err/000a/index.html
gh-pages/err/000b/index.html              gh-pages/err/000c/index.html
gh-pages/err/000d/index.html              todo/00-infrastructure/INDEX.md
todo/00-infrastructure/TODO-02-ai-development-system.md
todo/00-infrastructure/TODO-06-todo-metadata-layer.md
todo/00-infrastructure/TODO-09-repository-transfer-rizonetech.md
todo/12-user-platform-sdk/TODO-06-sdk-distribution.md
todo/15-installer-release/TODO-01-release-artifacts.md
todo/15-installer-release/TODO-03-update-server.md
todo/15-installer-release/TODO-05-github-release-community.md
scripts/test-ai-system.sh                 scripts/todo-graph/render.py

scripts/ matches need explicit handling, not "intentional retention":

• scripts/todo-graph/render.py:42 -- REPO_URL_BASE = "https://github.com/rizonesoft/impossible-os/blob/main". This is the generator constant for TODO graph node URLs in docs/infrastructure/todo-graph.md. The URL/badge/docs/generated-link sweep must update this constant in lockstep with the transfer; the regenerated graph then re-emits with the new owner. Do NOT manually edit the generated graph block. Risk row R10 names this file directly.
• scripts/test-ai-system.sh:396 -- a t_info log line ("verify repo/org Settings -> Copilot access = disabled for rizonesoft/impossible-os"). The URL/badge/docs/generated-link sweep should update this string to track the active owner; this is informational rather than a URL.

Notes for §6:

• SECURITY.md, CODE_OF_CONDUCT.md, AGENTS.md, CLAUDE.md returned zero matches in this scan -- they identify the project / Claude Code system but do not name the GitHub URL. They should not need owner-related edits.
• gh-pages/err/*/index.html is the largest group (15 files); the error-page header/footer link block is the most likely shared template that produces hundreds of references.
• rizonesoft.github.io appears 23 times under the expanded scan (5 in the narrow-path baseline -- the canonical / Open Graph / JSON-LD / visitor-counter spots on gh-pages/index.html plus one other landing-page surface; the additional 18 are spread across todo/ and self-references in this preflight doc).
• hits.sh/rizonesoft appears 5 times under the expanded scan (1 in the narrow-path baseline -- the active visitor-counter badge URL in gh-pages/index.html; the other 4 are self-references in this preflight doc and the Preflight Inventory section stamp prose that quote the pattern).

This inventory does NOT classify which references are the active GitHub repo (must change in §6) versus the brand rizonesoft.com (must NOT change, since the company name does not move). §6 walks the classification.

8. Remote Consumers (Notify or Re-Point)

9. Risk Register

Severity scale: Critical (Pages or repo unreachable for any duration), High (broken automation / lost setting / wrong policy), Medium (cosmetic or recoverable churn), Low (advisory).

§2 Receiving Org (rizonetech) Readiness Probe

Captures the pre-transfer readiness of the rizonetech organization. Combines public-API observations (token scopes gist, read:org, repo, workflow) with operator-only items that need either gh auth refresh -h github.com -s admin:org or a UI walkthrough. Each item names the authoritative source so the URL/badge/docs/generated-link sweep and post-transfer audit have a concrete reference.

Confirmed from public API (no admin:org needed)

Confirmed: operator + current admin membership

Org security defaults for NEW repositories (read off gh api orgs/rizonetech)

These are org defaults for newly created repos -- transferred repos preserve their own settings. The transfer does not regress against the source-repo baseline (which is also "all off"), but the org defaults being all-off means the transfer is not an automatic hardening event. Hardening (turning Dependabot alerts on, etc.) is a deliberate post-transfer step under the Post-Transfer Settings audit.

Operator-only items (require admin:org token scope OR UI walkthrough)

Pre-transfer checklist (concrete commands + UI walkthroughs for the operator)

The block below covers ALL six O-items: CLI commands for items with REST endpoints, and explicit UI walkthroughs for items where GitHub does not expose a public API (O1 Pages-domain verification, O3 org Pages policy, O5 Copilot Access). Walk every item -- skipping the UI-only ones (especially O5) lets the operator complete the visible CLI block and press transfer with policy gaps. After running gh auth refresh -h github.com -s admin:org once to upgrade the local token, the operator can replace the CLI walkthroughs:

# O1 -- Pages custom-domain verification for impossibleos.co (UI-only)
#   Walk: https://github.com/organizations/rizonetech/settings/pages
#   Add TXT record per the displayed challenge, then click Verify.
#   Do NOT confuse with org-identity domain verification under /settings/security.

# O2 -- Actions policy (must match or relax source-repo settings)
gh api orgs/rizonetech/actions/permissions
gh api orgs/rizonetech/actions/permissions/workflow
gh api orgs/rizonetech/actions/permissions/selected-actions  # only if allowed_actions != "all"

# O3 -- org Pages policy (UI-only; no stable public REST endpoint)
#   Walk: https://github.com/organizations/rizonetech/settings/pages
#   Confirm: "Public" or "Private and Public" selected; custom domains allowed.

# O4 -- rulesets / merge defaults / 2FA-required policy
gh api orgs/rizonetech/rulesets                                     # typically empty until first ruleset is imported
#   UI follow-up: https://github.com/organizations/rizonetech/settings/repository-defaults
#                 https://github.com/organizations/rizonetech/settings/rules

# O5 -- Copilot cloud-coding-agent / autonomous-agent PR enablement (UI-only -- MANDATORY)
#   Walk: https://github.com/organizations/rizonetech/settings/copilot/access
#   Set: "No access" OR "Selected members" with rizonesoft excluded from cloud-agent permission.
#   Required by docs/infrastructure/ai-system.md "Autonomous-Agent Boundary Policy".
#   Re-verify post-transfer in the post-transfer settings audit and the validation suite.

# O6 -- teams (currently zero)
gh api orgs/rizonetech/teams
#   UI: https://github.com/organizations/rizonetech/teams

If any item returns unexpected values OR the UI shows a state different from the documented expectation, stop the transfer and resolve before pressing the transfer button.

§3 Custom-Domain Continuity Plan

Plans the Pages custom-domain transition so https://impossibleos.co/ stays the canonical user-facing URL before, during, and after the transfer button. The default owner-based Pages URL (https://rizonesoft.github.io/impossible-os/ -> https://rizonetech.github.io/impossible-os/) IS allowed to change; the apex is not.

Canonical domain policy

Source-of-truth changes shipped in this section

DNS plan

Pages certificate continuity

Acceptable transient states (during/just-after transfer)

• The default Pages URL https://rizonesoft.github.io/impossible-os/ may stop redirecting cleanly for ~minutes while GitHub's repo-redirect machinery catches up; the apex serves through Fastly with the existing cert and is unaffected.
• The new default Pages URL https://rizonetech.github.io/impossible-os/ may show a TLS warning briefly while the cert reissues for the new owner.
• www.impossibleos.co may show an old answer for one TTL after the CNAME flip.
• The hits.sh visitor counter resets to zero on the namespace switch (rizonesoft.github.io/impossible-os -> impossibleos.co); historical counts are not retained. Acceptable for a private repo.

Validation commands -- pre-transfer

Run these immediately before pressing the transfer button. They confirm the source-owner state is what §1 baselined and that the TTL drop has propagated. Do NOT expect rizonetech.github.io to resolve yet -- the receiving repo doesn't exist until the transfer completes.

# State expected: source owner is still rizonesoft; www CNAME still targets rizonesoft.github.io.
curl -sIL --max-time 10 https://impossibleos.co/                        # expect 200; last-modified matches latest gh-pages deploy
curl -sIL --max-time 10 https://www.impossibleos.co/                    # expect 301 -> https://impossibleos.co/
curl -sIL --max-time 10 https://rizonesoft.github.io/impossible-os/     # expect 301 -> http://impossibleos.co/ (https_enforced=false)
getent hosts impossibleos.co                                            # 4 anycast IPv4 addresses (185.199.10[8-11].153)
getent hosts www.impossibleos.co                                        # CNAME chain ends at rizonesoft.github.io
# With BIND tools available:
dig +nocmd +noall +answer +ttl impossibleos.co A                        # apex A; TTL within provider's normal range
dig +nocmd +noall +answer +ttl www.impossibleos.co CNAME                # TTL should be the LOW value (60-300s) from the pre-transfer drop
gh api repos/rizonesoft/impossible-os/pages --jq '.cname,.html_url,.https_certificate.state,.https_enforced'   # expect: "impossibleos.co", "http://impossibleos.co/", "approved", false

If any line returns an unexpected status code, DNS answer, or Pages-settings value, stop and resolve before pressing the transfer button.

Validation commands -- post-transfer

Run these AFTER the transfer button is pressed AND the receiving Pages endpoint is verified live AND the www CNAME has been flipped to rizonetech.github.io. They form the §3 acceptance check (and the basis for the Validation suite):

# State expected: receiving owner is rizonetech; www CNAME flipped; cert reissued; old default Pages URL redirects via GitHub repo redirect.
curl -sIL --max-time 10 https://impossibleos.co/                        # expect 200; new etag may differ if Pages re-fetched the artifact
curl -sIL --max-time 10 https://www.impossibleos.co/                    # expect 301 -> https://impossibleos.co/
curl -sIL --max-time 10 https://rizonetech.github.io/impossible-os/     # expect 301 -> apex (or HTTPS-enforced apex once §5 flips the toggle)
curl -sIL --max-time 10 https://rizonesoft.github.io/impossible-os/     # INFORMATIONAL ONLY -- do NOT use as a rollback trigger. Per GitHub docs, repo URLs (github.com/owner/repo) auto-redirect on transfer, but Pages URLs (owner.github.io/repo) are owned by the user/org Pages namespace and do NOT auto-redirect. Post-transfer this commonly 404s or 302s to https://rizonesoft.github.io/ root. The apex (impossibleos.co) is the canonical post-transfer surface; do not gate the transfer on this owner-based Pages URL.
getent hosts impossibleos.co                                            # apex A unchanged (anycast IPs)
getent hosts www.impossibleos.co                                        # CNAME chain now ends at rizonetech.github.io
# With BIND tools available:
dig +nocmd +noall +answer +ttl impossibleos.co A
dig +nocmd +noall +answer +ttl impossibleos.co AAAA                     # empty unless §3 AAAA decision was revisited
dig +nocmd +noall +answer +ttl www.impossibleos.co CNAME                # target = rizonetech.github.io.
gh api repos/rizonetech/impossible-os/pages --jq '.cname,.html_url,.https_certificate.state,.https_certificate.expires_at,.https_enforced'   # expect: "impossibleos.co", apex URL, "approved" (cert reissued), expires_at >= cert reissue date, https_enforced still false until §5

If any line returns an unexpected status code or DNS answer, stop and roll back per §4 -- do NOT proceed with the URL/badge sweep until the apex serves cleanly under the new owner.

§4 Transfer Runbook and Rollback Window

The actual transfer is an operator action. This appendix captures the backup markers, the step-by-step procedure with copy-paste commands and expected outputs, and the rollback path. Do NOT skip steps; do NOT reorder. If any expected output differs, stop and consult the rollback section before proceeding.

Backup markers (snapshot captured 2026-04-27)

Preserve this block AS IS. Do not modify after capture. If rollback is needed, these are the canonical "known-good" values to compare against.

Optional belt-and-braces backup: before pressing transfer, run git bundle create /tmp/impossible-os-pre-transfer-$(date +%Y%m%d).bundle --all and stash the bundle file off-host. Restoration: git clone /tmp/impossible-os-pre-transfer-YYYYMMDD.bundle restored/ && cd restored && git push https://github.com/<owner>/impossible-os.git --all --tags. Useful only if the GitHub-side transfer corrupts history (extremely rare; documented for completeness).

Freeze rules (entire transfer + rollback window)

The freeze runs from "press transfer" until §7 validation suite is green for 24h continuously -- NOT just until §3 post-transfer validation passes. The longer window exists because rollback stays open the whole time, and any commits/tags/releases/Pages deploys landed during the window create a reconciliation problem if rollback fires.

For the entire window:

• No merges to main (the harness pre-commit hook already requires lint clean; reinforce by setting yourself a "no commit" reminder).
• No new releases or tag pushes.
• No gh-pages/** changes (the Pages workflow auto-fires on paths: ['gh-pages/**'] push and would race the transfer).
• No branch-protection / ruleset edits.
• No DNS changes EXCEPT the planned www CNAME flip (transfer Step 8 below) and the eventual TTL restoration (Step 10).

Communicate the freeze to anyone with rizonesoft write access (currently solo-dev: only rizonesoft, so the freeze is self-imposed).

Rollback reconciliation (if rollback fires after the freeze was violated): If new commits / tags / releases / deployments landed between transfer and rollback (i.e., the freeze was violated), the rollback procedure transfers ownership/DNS/remotes back but leaves the post-transfer changes IN the rolled-back repo. The operator must then either: (a) cherry-pick the post-transfer changes onto the source-owner repo's main after rollback, or (b) git push --force-with-lease origin main to reset to the backup-marker SHA 5d0df5ba (destructive, loses the post-transfer commits). Decide AT THE TIME based on the intent of the post-transfer changes; default is (a). This whole branch only matters if the freeze was violated -- which it should not be.

Transfer steps (in order)

Each step has expected output. STOP and consult the rollback section if observed output differs.

Step 1 -- Verify pre-transfer state (operator)

Run preflight §3 "Validation commands -- pre-transfer" block. Every line must produce the expected output. Specifically confirm:

• Apex https://impossibleos.co/ returns 200.
• gh repo view rizonetech/impossible-os returns Could not resolve (destination still clean).
• gh api repos/rizonesoft/impossible-os/pages --jq .cname returns impossibleos.co.

If www TTL has not been dropped to 60-300s yet (per §3 DNS plan), drop it now via the DNS provider UI and wait at least one previous-TTL window before continuing.

Step 2 -- Press the transfer button (operator, GitHub UI)

Walk: https://github.com/rizonesoft/impossible-os/settings -> bottom of page -> "Danger Zone" -> "Transfer" -> "Transfer ownership".

In the dialog:

• New owner: type rizonetech exactly (matches the canonical login; case-insensitive).
• Confirm by typing the repository name rizonesoft/impossible-os.
• Click "I understand, transfer this repository".

GitHub will redirect through an auth confirmation. The transfer typically completes within 30 seconds.

Expected confirmation signals (any one suffices to proceed to Step 3):

• The browser URL bar redirects to https://github.com/rizonetech/impossible-os (or to the org dashboard with a "transfer succeeded" banner).
• Loading https://github.com/rizonesoft/impossible-os/settings in a new tab returns 404 or redirects to the new path.
• gh repo view rizonesoft/impossible-os --json nameWithOwner from another terminal either returns Could not resolve (transfer complete) or follows the redirect to rizonetech/impossible-os.

If the transfer dialog returns an error (e.g., "You can't transfer this repository because of an issue") instead of redirecting, STOP and consult the Rollback section -- the transfer did not commit. Common causes: the destination org doesn't allow inbound transfers (fix in O3 / O4 of §2), or there's an active fork that blocks transfer.

Step 3 -- Accept the transfer (operator, GitHub UI for the org owner)

Some org configurations require explicit acceptance from the receiving side. Since rizonesoft IS admin of the rizonetech org and the transfer was initiated by the same identity, GitHub usually auto-accepts. If GitHub presents an "Accept transfer" prompt:

• Walk: https://github.com/organizations/rizonetech/settings/transfer-requests (if the page exists) OR check email for the transfer-acceptance link.
• Click Accept.

If no prompt appears within 60 seconds, the transfer has auto-accepted. Verify by visiting https://github.com/rizonetech/impossible-os (200 OK expected).

Step 4 -- Verify the new owner (operator + CLI)

gh repo view rizonetech/impossible-os --json nameWithOwner,owner,visibility,isPrivate
# Expected: {"nameWithOwner":"rizonetech/impossible-os","owner":{"login":"Rizonetech",...},"visibility":"PRIVATE","isPrivate":true}

gh api repos/rizonesoft/impossible-os --jq .url
# Expected: redirected URL (gh follows redirects; the response shows the new URL)
# OR the older format: {"message":"Moved Permanently",...}

curl -sIL --max-time 10 https://github.com/rizonesoft/impossible-os
# Expected: 301 -> https://github.com/rizonetech/impossible-os

Step 5 -- Update local remotes (operator, dev host)

cd /home/derickpayne/impossible-os
git remote set-url origin https://github.com/rizonetech/impossible-os.git
git remote -v
# Expected:
#   bootloader  https://github.com/rizonesoft/impossible-os-bootloader.git (fetch + push)
#   origin      https://github.com/rizonetech/impossible-os.git (fetch + push)

git fetch origin
git pull --ff-only origin main
# Expected: "Already up to date." (no new commits -- the freeze held)

The bootloader remote stays unchanged -- transferring impossible-os-bootloader is a separate decision and is OUT OF SCOPE for TODO-09.

Step 6 -- Verify Pages settings preserved (CLI)

gh api repos/rizonetech/impossible-os/pages
# Expected critical fields:
#   "cname": "impossibleos.co"      -- CRITICAL; if empty or different, the custom domain detached (see Rollback below)
#   "https_certificate.state": "approved" or "issued"  -- if "provisioning" or "errored", wait up to 1h then re-check
#   "build_type": "legacy" (unchanged) OR "workflow" (if GitHub auto-promoted)
#   "source": branch=gh-pages OR workflow source (either is fine)
#   "https_enforced": false (do NOT flip on yet -- §5 owns it)

If cname is empty or different from impossibleos.co, re-set it via the repo Pages UI https://github.com/rizonetech/impossible-os/settings/pages: paste impossibleos.co into the custom-domain field, click Save. GitHub may show "DNS check unsuccessful" briefly while it re-validates -- tolerate for ~minutes.

Step 7 -- Trigger Pages re-deploy (operator, optional)

If the Pages workflow has not auto-fired since the transfer (no gh-pages/** push has happened), kick it manually:

gh workflow run pages.yml -R rizonetech/impossible-os
gh run list -R rizonetech/impossible-os -w pages.yml -L 1
# Expected: a new run with status=in_progress, then status=completed conclusion=success within ~30s.

If conclusion=failure, read the run log; the Artifact storage quota issue from §1 may resurface under a fresh enterprise-org budget but is now lower-probability (the quota is per-account and the new account is fresh).

Step 8 -- Apply the www CNAME flip (operator, DNS provider UI)

ONLY after Steps 4-7 confirm the new owner is serving cleanly. At the DNS provider:

• Locate the existing www.impossibleos.co CNAME record (rizonesoft.github.io.).
• Edit the target to rizonetech.github.io..
• Keep the low TTL (60-300s) for now -- the post-transfer validation needs it short.
• Save.

Wait one TTL window (60-300s); then verify:

getent hosts www.impossibleos.co
# Expected: chain ends at rizonetech.github.io with the GitHub Pages anycast IPs.
dig +nocmd +noall +answer +ttl www.impossibleos.co CNAME
# Expected: "www.impossibleos.co. <ttl> IN CNAME rizonetech.github.io."

Step 9 -- Run preflight §3 "Validation commands -- post-transfer" (operator)

Execute every command in the post-transfer block. The compact go/rollback table below mirrors the §3 expected outputs at the decision point so you don't have to scroll during the freeze window:

If any required line fails (rows marked Rollback), STOP and proceed to the Rollback section below immediately.

Step 10 -- Restore TTL to normal (operator, ~24h after Step 9 green)

After all post-transfer validation has been green for 24h continuously, restore www.impossibleos.co CNAME TTL to the provider's normal value (typically 3600-86400s) at the DNS provider UI. The temporary low TTL was only needed for the transfer window.

Expected output:

dig +nocmd +noall +answer +ttl www.impossibleos.co CNAME
# Expected: "www.impossibleos.co. <TTL>  IN  CNAME  rizonetech.github.io."
# where <TTL> >= the provider's normal value (e.g., 3600 or higher).
# If <TTL> is still showing the low pre-transfer value (60-300), wait one previous-TTL window for the new TTL to propagate, then re-check.

Rollback (if any post-transfer step fails)

The rollback window stays open until the §7 validation suite passes. Rollback means transferring back to the previous owner, NOT deleting and recreating repositories (deletion would break GitHub's redirect table permanently).

Wall-clock budget:

If the degraded case looks unavoidable (low TTL didn't propagate AND post-transfer validation already failed), proceed with rollback anyway -- the alternative is leaving the apex broken longer. The temporary www outage during the TTL window is finite; a broken apex under a partially-transferred state can be open-ended.

Rollback step 1 -- Reverse the transfer (operator, GitHub UI)

Walk: https://github.com/rizonetech/impossible-os/settings -> Danger Zone -> "Transfer". Set new owner: rizonesoft. Confirm.

If GitHub rejects the reverse-transfer (e.g., due to redirect-table state or a transient API error), STOP and escalate to GitHub Support at https://support.github.com/contact. Do NOT attempt to "free" the old path by creating, forking, or renaming any repository at rizonesoft/impossible-os -- per the redirect-window invariant in this doc, recreating the old path permanently deletes the redirect table and makes recovery harder. Repository redirects are a GitHub-internal feature, not a Pages setting; there is no documented user-facing UI to delete them. If reverse-transfer remains blocked after Support engages, fall back to the optional git bundle belt-and-braces backup (see Backup markers above) and restore to a fresh repo path under the new owner (do NOT recreate the old path).

Rollback step 2 -- Restore the www CNAME (operator, DNS)

Edit www.impossibleos.co CNAME back to rizonesoft.github.io.; wait one TTL window.

Rollback step 3 -- Update local remotes back

git remote set-url origin https://github.com/rizonesoft/impossible-os.git
git fetch origin

Rollback step 4 -- Verify pre-transfer state restored

Re-run preflight §3 "Validation commands -- pre-transfer". Every line must match the original expected output.

If rollback succeeds, file an issue capturing what failed during the forward transfer; do not retry until the root cause is understood. If rollback FAILS (e.g., GitHub refuses the reverse-transfer), preserve the local clone and restore from git bundle if needed.

Forbidden during the redirect window

GitHub redirects https://github.com/rizonesoft/impossible-os -> https://github.com/rizonetech/impossible-os automatically after the transfer. Recreating a repository at the old path destroys the redirect table. Do NOT:

• Create a new empty rizonesoft/impossible-os repo for any reason.
• Fork-and-rename a different repo into the old path.
• Allow any tooling to auto-create the old path (e.g., automated repo provisioning scripts pointing at the user account).

Rule of thumb: until §7 has been green for at least the GitHub-documented redirect-retention window, treat rizonesoft/impossible-os as a tombstone path.

§5 Post-Transfer Settings, Workflows, Secrets, and Environments Audit

Captured 2026-04-27 evening, immediately after the transfer completed. Each row compares the live post-transfer state under rizonetech/impossible-os to the §1 baseline captured under rizonesoft/impossible-os. Most settings preserved verbatim; three real findings caught -- one drift that pre-dated the transfer, two transfer-induced.

Preserved verbatim (matches §1 baseline)

Findings (3 real issues; 1 drift, 2 transfer-induced)

Operator-only items (require admin:org / UI -- still pending from §2 / §3)

These were captured in §2 Receiving Org Readiness Probe. Re-listed here for the post-transfer audit:

• O1 Pages custom-domain re-verification under new owner -- per §3 the pages.cname value carried over (impossibleos.co); GitHub may re-verify silently. Walk https://github.com/rizonetech/impossible-os/settings/pages "Verified custom domains" if the cert reissues or the domain shows "DNS check unsuccessful".
• O2 Org Actions policy -- repo-level Actions policy is preserved (per the table above); the org-level envelope still needs the admin:org probe.
• O3 Org Pages policy -- still UI-only check at https://github.com/organizations/rizonetech/settings/pages.
• O4 Org rulesets / merge defaults / 2FA enforcement -- the source-repo ruleset migrated cleanly (id preserved); the org-level envelope still needs the admin:org probe.
• O5 Copilot Access policy -- mandatory check at https://github.com/organizations/rizonetech/settings/copilot/access; per the Autonomous-Agent Boundary Policy the org must NOT enable cloud coding-agent or autonomous-agent PR enablement for this repo.
• O6 Org teams -- still zero teams; consider adding maintainers team containing @rizonesoft once F3 is fixed (or in lockstep with it).
• https_enforced flip -- intentionally still false; flip on at the operator's discretion once the cert reissue (if any) settles. UI: https://github.com/rizonetech/impossible-os/settings/pages "Enforce HTTPS" toggle, OR gh api -X PUT repos/rizonetech/impossible-os/pages -f https_enforced=true after refresh-with-admin:org.

Summary table (for §7 validation suite)

How to Re-Run This Inventory

The exact commands used to capture this baseline:

# Repository identity
gh repo view rizonesoft/impossible-os --json nameWithOwner,owner,visibility,isPrivate,defaultBranchRef,description,homepageUrl,isArchived,isFork,isTemplate,isInOrganization,hasIssuesEnabled,hasDiscussionsEnabled,hasWikiEnabled,hasProjectsEnabled,isSecurityPolicyEnabled,isBlankIssuesEnabled,repositoryTopics,id,sshUrl,url,createdAt,pushedAt,licenseInfo,deleteBranchOnMerge,squashMergeAllowed,rebaseMergeAllowed,mergeCommitAllowed

# Pages + environment + deployments
gh api repos/rizonesoft/impossible-os/pages
gh api repos/rizonesoft/impossible-os/environments
gh api repos/rizonesoft/impossible-os/deployments --jq '.[0:3]'
gh run list -R rizonesoft/impossible-os -w pages.yml -L 3

# Live domain + DNS (require BIND tools or Python)
for u in https://impossibleos.co/ https://www.impossibleos.co/ https://rizonesoft.github.io/impossible-os/ http://impossibleos.co/; do
  curl -sIL --max-time 10 "$u" | head -25
done
getent hosts impossibleos.co
getent hosts www.impossibleos.co
dig +nocmd impossibleos.co A          # if available
dig +nocmd impossibleos.co AAAA       # if available
dig +nocmd www.impossibleos.co CNAME  # if available

# Actions + workflows + secrets + variables + branch protection + rulesets
gh api repos/rizonesoft/impossible-os/actions/permissions
gh api repos/rizonesoft/impossible-os/actions/permissions/workflow
gh workflow list -R rizonesoft/impossible-os --all
gh secret list -R rizonesoft/impossible-os
gh variable list -R rizonesoft/impossible-os
gh api repos/rizonesoft/impossible-os/branches/main/protection
gh api repos/rizonesoft/impossible-os/rulesets

# Webhooks / deploy keys / vulnerability alerts / dependabot
gh api repos/rizonesoft/impossible-os/hooks
gh api repos/rizonesoft/impossible-os/keys
gh api repos/rizonesoft/impossible-os/vulnerability-alerts --silent && echo enabled || echo disabled
gh api repos/rizonesoft/impossible-os/automated-security-fixes

# Access
gh api repos/rizonesoft/impossible-os/collaborators

# Receiving org readiness
gh api orgs/rizonetech --jq '{login,plan,public_repos,total_private_repos,owned_private_repos,members_can_create_repositories,billing_email}'
gh repo view rizonetech/impossible-os --json nameWithOwner   # MUST 404
gh api user/memberships/orgs/rizonetech

# Hard-coded owner references (expanded path set: includes todo + scripts;
# render.py:42 holds REPO_URL_BASE so scripts/ is mandatory).
#
# Step 1 -- compare against the post-doc baseline (expected: 39 files / 364 matches):
PATTERN='rizonesoft/impossible-os|github\.com/rizonesoft|rizonesoft\.github\.io|hits\.sh/rizonesoft'
PATHS='README.md CONTRIBUTING.md SECURITY.md CODE_OF_CONDUCT.md AGENTS.md CLAUDE.md docs gh-pages .github todo scripts'
rg -l "$PATTERN" $PATHS | wc -l                                    # file count
rg -n "$PATTERN" $PATHS | wc -l                                    # total matching lines (matches "364" semantics in this doc)
for p in 'rizonesoft/impossible-os' 'github\.com/rizonesoft' 'rizonesoft\.github\.io' 'hits\.sh/rizonesoft'; do
  echo "[$p] $(rg -c "$p" $PATHS 2>/dev/null | awk -F: '{s+=$NF} END {print s}')"
done                                                                # per-pattern counts
#
# Step 2 -- locator (only run after Step 1 shows drift; emits hundreds of lines):
rg -n "$PATTERN" $PATHS

Re-run the full block immediately before §4 transfer to detect any drift since the baseline date.