Move the apex to yellowpine.com and make .dev the redirect

[cansin]

yellowpine.com is finally in the Porkbun account. This moves the site onto it and turns yellowpine.dev into the redirect domain, reversing the topology chosen on 2026-09-08 (which parked the site on .dev precisely because .com was not ours to point anywhere).

The defect this closes

The page has advertised hello@yellowpine.com since 2026-09-08, in the masthead and again under Get in touch. .com was not ours then, and when it arrived it came carrying the previous owner's Mailgun MX records and zero forwards of ours.

Every message sent to the address on the homepage went to servers we do not control. Nothing in the suite caught it, because no test related the contact address to the domain the site is served from.

tests/site.test.mjs now asserts that relationship. It was written against the live page first, where it failed:

AssertionError: contact address is not on yellowpine.dev: hello@yellowpine.com

and only then was the domain flipped.

What changed

File	Change
CNAME	yellowpine.dev → yellowpine.com
index.html	canonical, og:url, og:site_name. The two mailto: links already said .com and are untouched.
tests/site.test.mjs	DOMAIN flipped; new invariant tying every mailto: to DOMAIN; header renumbered.
README.md	Title, links, inverted topology line, rewritten Deploying.
package.json	Description.
docs/.../2026-09-10-yellowpine-com-apex-design.md	New. The 2026-09-08 spec is left as written.

Deploying is rewritten rather than retitled: its reasoning rested on .dev being HSTS-preloaded, which made HTTPS free. .com is not, so Enforce HTTPS is now something to set rather than assume. The ordering footgun is written down there too — DNS must point at GitHub before the domain lands in CNAME, or validation fails and GitHub never retries.

Merge order

DNS for yellowpine.com is being pointed at GitHub Pages before this merges, so Pages does not register a custom domain whose DNS still resolves elsewhere. .dev stays fully live until the moment this lands.

Known transitional risk, accepted: Pages serves exactly one custom domain, so between this merge and Porkbun issuing a certificate for yellowpine.dev, .dev is dark — and being HSTS-preloaded at the TLD level it hard-fails rather than degrading. The sequence puts that gap on the domain being retired, never on the live one.

Tests

npm test — 20/20 with network checks enabled.

🤖 Generated with Claude Code

https://claude.ai/code/session_01Q5nJ8eKEb1wm5tCzxipXHS

[Copilot]

🟡 Changes recommended

Four moderate findings remain in the migration documentation, metadata checks, and contact-address validation.

Once you've addressed the issues Copilot identified, you can request another Copilot review.

Pull request overview

Moves the GitHub Pages site apex from yellowpine.dev to yellowpine.com and documents .dev as the redirect domain.

Changes:

• Updates CNAME, metadata, README, and package description.
• Adds contact-domain validation tests.
• Adds DNS migration and deployment documentation.

File summaries

File	Summary	Final review comments
tests/site.test.mjs	Updates domain assertions and validates mailto: links.	Moderate (1 vote): Strip query parameters before validating mailto: addresses. Moderate (1 vote): Reject malformed addresses containing multiple @ characters.
README.md	Documents the new domain topology and deployment process.	No final comments.
package.json	Updates the project description.	No final comments.
index.html	Updates canonical and Open Graph metadata.	Moderate (3 votes): Assert og:url and og:site_name against DOMAIN, rather than only checking tag existence.
docs/superpowers/specs/2026-09-10-yellowpine-com-apex-design.md	Records migration sequencing and DNS decisions.	Moderate (2 votes): Resolve the conflict between deleting .dev mail records and preserving the hosted inbox.
CNAME	Sets yellowpine.com as the custom domain.	No final comments.

Review details

Suppressed comments (2)

tests/site.test.mjs:96

• RFC 6068 permits query parameters on a mailto: URI, such as mailto:hello@yellowpine.com?subject=Hello. Including that query in address makes this assertion reject an otherwise valid contact link because the parsed domain becomes yellowpine.com?subject=Hello; strip the query before validating the address.

    const address = href.slice('mailto:'.length);

tests/site.test.mjs:98

• The new invariant does not actually reject every off-domain address: address.split('@')[1] is still yellowpine.com for a malformed value such as hello@yellowpine.com@attacker.example, so that link would pass despite not being a valid address on this domain. Validate that there is exactly one @ (and compare the part after it) before asserting the domain.

      address.split('@')[1],

• Files reviewed: 6/6 changed files
• Comments generated: 2
• Review effort level: Lite

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[cansin]

Review findings — all five addressed

Reviewed at high effort against the full branch diff. Every finding was real; none were dismissed.

#	Finding	Severity	Resolution
1	Domain guard missed og:url / og:site_name	medium	Fixed — new guard, proven by mutation
2	Spec claimed npm test gates checks it cannot perform	medium	Fixed — verification section rewritten
3	-f cname="" cannot clear the Pages domain	medium	Fixed — now -F cname=null
4	Spec non-goal contradicted step 6	low	Fixed — reworded
5	Anchor text not checked against mailto: href	low	Fixed — new guard, proven by mutation

1 — the guard had a hole exactly where the PR claimed to close one

hrefsIn() matches only href=/src=, so <meta property="og:url"> never entered allHrefs, and page has the metadata a shared link needs asserted those tags exist without ever reading their values. Reverting og:url alone demonstrates it:

✔ CNAME pins the custom domain
✔ page declares the canonical URL and matches CNAME
✖ the social metadata points at the same domain

CNAME and canonical both stay green. Without the new guard, that mutation ships.

5 — same class, second instance

The address is a link target and visible text. Reverting only the text:

✔ the contact address is on the domain the site serves
✖ the contact address reads the same as it links

3 — the emergency command didn't work

The Pages API removes a custom domain only on a JSON null; gh's -f sends raw strings. The one command written down for a failed certificate would have errored at the moment it was needed. Now -F cname=null, with the reason recorded beside it.

2 — the spec overstated its own gate

The apex is excluded from the liveness test by isSelf, nothing fetches .dev, and nothing tests mail delivery. A certificate that never issued would have kept CI green forever. The verification section now states plainly that those four checks are manual, and that they — not CI — are the real gate for this change.

4 — self-contradiction in the spec

The non-goal said the .dev trial inbox was untouched; step 6 deletes the MX and SPF it would need. Reworded: neither set up nor cancelled, lapses 2026-09-22, and nothing reaches it meanwhile — which is what redirect-only means.

npm test — 22/22 with network checks enabled.