The Problem with Day 2

Day 2 ended with a beautiful site. Neon Brutalist palette, light/dark toggle, design tokens wired up properly. It looked great. But I couldn't actually use it.

The admin login page accepted the correct password and then… nothing happened. No error, no redirect, no feedback. Just the same login form staring back at me. The edit button on posts linked to a recording page that ignored the fact that you were editing — it always started fresh. The admin dashboard had one big "Record" button and no way to find an existing post.

Day 3 was about turning a pretty blog into a functional one. Less visual, more plumbing. The kind of session where everything you build is invisible to readers but makes the difference between "I'll update that later" and actually updating it.

The Silent Login Bug

This one was subtle. The login form called fetch to set a session cookie, then used Next.js router.push("/admin") to navigate. In the App Router, router.push is a soft navigation — it fetches a React Server Component payload over the wire and patches the DOM. No full page reload.

The problem: after fetch sets a cookie, a soft navigation can reuse a stale client-side cache or have the middleware redirect silently swallowed. The browser has the cookie, but the RSC request either doesn't send it or the middleware response gets eaten by the router. The user lands right back on /admin/login with zero feedback.

The fix is almost embarrassingly simple:

// Before: soft navigation, cookie may not propagate
router.push("/admin")

// After: hard navigation, browser sends fresh cookies
window.location.href = "/admin"

Same fix for logout. window.location.href forces the browser to make a full request with the current cookie jar. It's the standard pattern for auth state transitions in Next.js App Router — any time cookies change, don't trust soft nav.

This is the kind of bug that doesn't show up in development. You're already authenticated, the cache is warm, everything works. It only bites you in production when a real user (me, from my phone) hits the cold path.

Admin Access

Two small UX fixes while I was in the auth flow:

Footer link. Added a subtle "Admin" link in the site footer — dimmed by default, lights up on hover with the primary accent. No security implications; the middleware blocks everything without a valid JWT. But now I don't have to type /admin from memory on a phone keyboard.

Visitor-friendly login page. If a non-admin stumbles onto /admin/login, they now see "This area is for the site owner" with a "Back to the blog →" link instead of a bare password field. Small thing, but it's the difference between a page that looks broken and one that looks intentional.

The Edit Pipeline

This was the biggest fix of the session. The blog had a voice recording feature from Day 1 — talk into the browser, Claude generates an MDX post, one-click publish to GitHub. But it was create-only. The "Edit" button on each post linked to /admin/record?edit=slug, and the record page completely ignored the query parameter. Every recording session created a new post.

The fix touched five files:

1. Record page reads ?edit=slug via useSearchParams (wrapped in a Suspense boundary — App Router requires this for client-side search params)
2. On mount in edit mode, fetches the existing post content from the API
3. Generation API receives the existing content alongside the new transcript, so Claude merges rather than rewrites
4. Publish call uses PUT (update) instead of POST (create) when in edit mode
5. PostPreview locks the slug field and shows "Update on GitHub" instead of "Publish to GitHub"

The useSearchParams + Suspense requirement is a Next.js App Router detail worth calling out. Without the Suspense boundary, the page throws during static rendering because search params aren't available server-side. It's documented, but it's the kind of thing that bites you when you're porting a pattern from Pages Router.

Now the voice-to-blog pipeline works in both directions: create from scratch, or record additional context and merge it into an existing post. Same UI, same flow, different HTTP verb.

Admin Dashboard Overhaul

The original admin dashboard had three cards: Record, Manage, Settings. Record was the only one that did anything useful. For Day 3, it became two distinct entry points:

Record New Post — same as before, links to /admin/record with no query params.

Edit Existing Post — a searchable dropdown picker. Type to filter posts by title (case-insensitive substring match), click to navigate to /admin/record?edit=slug. The dropdown is scrollable (max-h-64) and closes on click-outside via a pointerdown listener. Designed to handle hundreds of posts without pagination — client-side filtering is fine at blog scale.

Inline Text Editing

The voice recording flow is great for substantial rewrites, but overkill for fixing a typo. So I added a third option: inline text editing directly on the blog post page.

The admin bar on each post (visible only when logged in) expanded from two actions to three:

The inline editor loads the raw MDX source, lets you edit in place, and saves via PUT /api/posts. No page navigation, no recording session, no Claude generation. Just fix the typo and hit Save.

This is the feature that changed how I use the site. Before, fixing a date typo meant opening the voice recorder, describing the change, waiting for Claude to regenerate, and publishing. Now it's: click Type Edits, fix the character, Save. Five seconds instead of two minutes.

Public Changelog

Every edit should be transparent. I added a changelog field to the post frontmatter — an array of {date, summary} entries:

changelog:
  - date: '2026-04-16'
    summary: Fixed Koto -> Coder typo

A collapsible <Changelog> component renders between the post header and content. Collapsed by default — "▸ 1 update" or "▸ N updates" — and expands on click to show the full history. Subtle monospace styling that doesn't compete with the post content.

The changelog entries are generated automatically based on the edit type:

• Inline edits get a summary derived from a line-level diff: "Minor text edits," "Edited N lines," or "Revised post content (N lines changed)" depending on scope
• Voice recording edits default to "Updated via voice recording"
• Manual summaries are still supported if you want to be specific

No AI needed for the diff summaries — just line counting. No commit SHAs, file paths, or system information exposed. Only reader-facing descriptions.

One gotcha: the initial changelog text used text-outline-variant/60, which was nearly invisible in light mode. Bumped to text-on-surface-variant for proper readability in both themes. Another reminder to test both modes after every UI change.

The Blog Post Consolidation

A meta moment: during Day 3, I used the voice recording feature to publish a post about the Google Stitch workflow from Day 2. Then I realized it belonged in the Day 2 post, not as a standalone entry.

So I merged it — the brand guidelines trick and the mobile pipeline section got folded into the Day 2 post as new subsections, and the standalone third post got deleted. This is the kind of editorial decision that's easy when your content is just files in git. No CMS to wrestle with, no database records to reconcile. Delete a file, edit another file, push.

What I Learned

Soft navigation is not your friend during auth transitions. Next.js App Router's router.push is a client-side RSC fetch. If you've just set or cleared a cookie, the soft navigation may not reflect that. Use window.location.href any time authentication state changes. This isn't a bug — it's a fundamental aspect of how RSC caching works.

Build the editing tools early. I should have built inline editing on Day 1. Every session since has involved going back to fix small things in previous posts — typos, date errors, wording tweaks. Without quick inline editing, each fix was a multi-step process through the voice pipeline. The moment I had a textarea and a Save button, my publishing velocity doubled.

Transparency scales trust. The public changelog is a small feature, but it signals something: this content is alive, corrections are acknowledged, and readers can see what changed. For a blog about building in public, that's table stakes.

Each session fixes friction from the last one. Day 1 built the foundation. Day 2 made it look right. Day 3 made it usable. The pattern is consistent: build something, use it for real, discover what's broken or slow, fix it next session. The site isn't being designed upfront — it's being discovered through use.

By the Numbers

• 1 silent auth bug fixed (soft nav → hard nav)
• 5 files changed to make the edit pipeline work
• 3 admin actions per post (type edits, record edits, delete)
• 1 new component (InlineEditor)
• 1 new frontmatter field (changelog)
• 2 blog posts retroactively given changelog entries
• 1 post merged into another, 1 deleted
• 0 design changes — all plumbing, all invisible to readers