Phase 3 re-run: renames pass, /almanac/ does not

[FDelporte]

Re-ran every Phase 3 check against the live site now that cutover has happened, and recorded the results in CUTOVER.md.

The renames blocker is closed

Rule 4b is deployed. All 14 renames answer 302 and end 200, checked one by one rather than trusting the three the loop covers — including the parts the rule was written to get right: page/N/ and feed/ tails carried through, the ai-ml split (bare → /ai/, deeper → machine-learning/), and the cascade guard (surveys/, interviews/, tutorials/, vs-code/ … all 200, none re-matched by the rule that produced them).

One new blocker: /almanac/ and /almanac 404

Both redirected to https://javaalmanac.io/ on WordPress — plugin rules 69 and 70, 644 and 23 recorded hits, the first used 2026-09-19, two days before cutover. Rule 2 only matches ^/almanac/(jdk|java)-([0-9]+), so the section's own front door was never carried. /almanac/anything/ 404s too.

They are not in "What was deliberately NOT carried over", so this is an oversight rather than a decision. A Hugo alias can't fix it — an alias resolves against baseURL and can't point off-site — so it needs Cloudflare. The PR writes out a widened rule 2 that covers all three shapes with one nested regex_replace pair, and adds both bare forms to the verification loop.

How it stayed invisible is the part worth keeping: the loop tests /almanac/jdk-17 and /almanac/java-8 and nothing else. I found it by testing all 75 enabled non-regex plugin rules from the SQL dump instead of spot-checking four — 73 end 200, these two don't. The dump makes that list reproducible, and the PR records the query.

Three "needs a browser" items shrank

view counter	partials/views-beacon.html just sendBeacons a POST, so curl -X POST /api/views/hit/<key> is the same request: 204, and the key goes up by one (5052 → 5053). Also confirms the dump-based re-import landed — 0 post keys now sit below the database, against 2,169 before.
analytics	The Phase 0 question — is Ketch's Google Consent Mode plugin enabled on foojay_io? — is answered yes by the property's own config: plugins.googletag is present, and _ga/_gid map to the analytics purpose. Only the banner-to-beacon path still needs a browser.
search	pagefind-entry.json reports 2,861 pages indexed, which is the part that could silently be empty. Running a query is still client-side.

Mail: MX → foojay-io.mail.protection.outlook.com and the full SPF include list are intact — what the "touching MX breaks mail" warning in Phase 2 is about. Sending a real test is still worth doing.

Everything else

Indexable (no noindex, Disallow: empty, sitemap line present), no trial URLs leaked, www and http both 301 to the apex, comments archive + giscus loader in the HTML, proxy on (cf-ray present, Cloudflare anycast). All 22 top-level pages and feeds 200; a 46-URL sample of /today/ posts from the live sitemap (2,740 URLs) 200. The two posts repaired from the dump are live and correct — the SVG-fonts article now has its body and both images, and calling-microservices-in-java has its hero.

Still open, for a human

• [BLOCKER] the /almanac/ rule — needs Cloudflare access.
• Analytics beacon — accept the Ketch banner in a normal window, confirm /g/collect with tid=G-GS21L12HYK. My sandbox can't reach Google's endpoints at all, so I can't do this one even partially.
• Send a test to hello@foojay.io.
• Resubmit sitemap.xml in Search Console.
• Phase 4's 301 flip is correctly still pending — every rule answers 302.

Noted, both pre-existing and unrelated to cutover: no _dmarc.foojay.io record, and no HSTS header.

🤖 Generated with Claude Code

Summary by CodeRabbit

• Documentation
  • Updated cutover verification records for category renames, redirects, aliases, view-count synchronization, search indexing, and DNS/mail checks.
  • Documented expanded verification coverage for bare /almanac/ paths and the corresponding Cloudflare redirect rule fix.
  • Recorded remaining blockers affecting analytics, mail, sitemap generation, and /almanac/ behavior.

[coderabbitai]

Note

Currently processing new changes in this PR. This may take a few minutes, please wait...

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Advanced

Run ID: 1feeb607-d91b-4d85-bf20-01d58d228059

📥 Commits

Reviewing files that changed from the base of the PR and between 2bb4ea5 and 6fc77fd.

📒 Files selected for processing (1)

• CUTOVER.md

 ________________________________________________________________
< CodeHamster is my sidekick. She powers the GPU with her wheel. >
 ----------------------------------------------------------------
  \
   \   (\__/)
       (•ㅅ•)
       / 　 づ

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Commit to this branch
• Create a new PR

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[Copilot]

Copilot review overview

🟡 Changes recommended

The runbook still contains stale rename instructions and an outdated canonical Rule 2 definition that could lead to incorrect deployment.

Get a fresh assessment by requesting another Copilot review.

Review effort: Lite
Findings: 1

Open (1)

• Update stale runbook references to reflect verified redirects · New

What changed in this PR

Updates CUTOVER.md with post-cutover verification results, closes the category rename blocker, and documents the remaining /almanac/ redirect blocker.

Changes:

• Records successful checks for redirects, aliases, views, search, analytics configuration, and DNS/mail.
• Adds a widened /almanac Cloudflare rule and verification paths.
• Documents remaining browser and operational follow-ups.

File	Description
CUTOVER.md	Records Phase 3 rerun results and redirect remediation steps.

---

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