GitHub Pages binds one custom domain to one repo, and the aiste-io repo already owns the aiste.io apex domain as a hand-authored, no-build-step landing page. Decided: the new repo gets its own GitHub Pages deployment on reads.aiste.io rather than a /my-substack-reads path merged into the aiste-io repo. Considered pushing built output into aiste-io as a subfolder, but rejected it — a subdomain fully decouples newsletter-processing/publishing from the landing-page repo and sidesteps the one-repo-per-custom-domain constraint without ever touching aiste-io.