Where I'm at
Every single page on panke.app was showing the homepage.
Not a 404. Not a server error. Just the homepage — calm, clean, completely wrong — no matter what URL you clicked. Journal entries, guides, the profile page. All of them resolving to the front door, as if the rest of the site had simply ceased to exist overnight.
I stared at it for a moment before opening my laptop, hoping it was a phone rendering glitch.
It wasn't.
• • •Every single page on panke.app was showing the homepage. Not a 404. Not a server error. Just the homepage — calm, clean, completely wrong.
The first bug
The first deploy looked fine. 125 files uploaded to Cloudflare Pages. Progress bar, checkmarks, success message. Everything the deployment UI is designed to make you feel confident about.
But something was wrong with how those files were being served. Every subpage — /journal, /guides, /profile — was returning index.html instead of its own content. The URLs were correct. The links worked. The routing logic was fine. Cloudflare was just ignoring all of it and sending everyone home.
I redeployed with the correct file structure. Pages started loading.
Bug one: solved. On to bug two.
• • •The second bug
The pages loaded. Visually. The layout was there, the header was there, everything looked right. But nothing worked. Every dynamic element was frozen on "loading..." JavaScript never ran.
The culprit was in the CSP headers inside _headers. The Content Security Policy had script-src 'self' — which is technically correct, secure, the kind of thing a tutorial tells you to write. But without 'unsafe-inline', it blocked every inline script on the site. Silently. No error in the UI, no red text, just... frozen.
The fix was five words: add 'unsafe-inline' to the CSP directive.
Five words. Written once. An afternoon of broken pages.
• • •The third bug
Two bugs fixed, one category of pages still wouldn't load. The profile, community-journals, and join pages were stuck — not frozen this time, just refusing to resolve correctly.
The cause was ES modules with relative imports. The pages used ./js/config.js to reference their scripts. In a normal file system that works perfectly. But Cloudflare strips the .html extension from URLs. So when the browser sits at /profile and tries to resolve ./js/config.js, the path calculates from the wrong base. The module chain broke at the first import.
I rewrote all three pages. Ripped out the ES module structure entirely, replaced everything with plain inline JavaScript. No imports. No module chain. No relative paths to resolve wrong.
Inelegant. Absolutely works.
• • •The GitHub backup
With the site back up, I turned to something I should have done two weeks ago: a proper GitHub backup.
The repo is pankebuild/Openclaw-. First push attempt came back with "Resource not accessible by integration" — the token didn't have repository permissions. Regenerated with the correct scopes. Second attempt pushed cleanly.
128 files. The full site. On GitHub, timestamped, restorable.
Day 7 taught me to back up before touching production. Today taught me that "backed up to GitHub" is only true if the token you used actually had write access.
• • •The system kept running
While all of this was happening — the debugging, the rewrites, the permission errors — the automated system ran without interruption. Morning briefing at 7 AM. Aster content drafts on schedule. X mirror active. Bookmark digests for March 3 through 5 compiled and delivered. Market briefings in the afternoon and evening.
Nineteen days ago, none of this existed. Today I spent six hours debugging a broken deployment and the machine handled everything else on its own. I didn't touch the automations once.
That's still remarkable to me. Even on a day where the site was broken, the system wasn't.
• • •Nineteen days of building teaches you what the machine is supposed to sound like. So when it goes quiet, you hear it.
End-of-day reflection
Four bugs. All of them silent.
That's what today taught me — not the specific fixes, but the type of failure. None of these errors announced themselves. The deployment UI said success. The pages loaded visually. The URLs resolved. The CSP said 'self' which is correct.
Everything looked fine, and everything was broken.
Silent failures are a different category from loud ones. When the server crashes, you know. When the API returns 500, you know. But when Cloudflare quietly serves the wrong file, when CSP silently suppresses your JavaScript, when a relative import resolves to the wrong path without throwing — nothing tells you. You have to notice that something isn't working and go looking.
The debugging skill isn't finding bugs once you know they exist. It's developing enough baseline sense of what "working" looks and feels like that you can detect when something is subtly wrong before you have evidence.
Day 1 me would have assumed the white pages were intentional. Day 19 me knew immediately something was off.
Day 19 of ∞ — @astergod Building in public. Learning in public.