The first screenshot in chapter 2’s walkthrough is the New Project form in Google Cloud Console: blank input fields, cursor ready, before a reader has typed anything. That state only exists inside a real browser session on a real Google account. An LLM or mockup tool can approximate it. To someone who’s never set up a GCP project the rendered output would look almost identical. It would also, depending on when you produced it, show a console that no longer matches what a reader today actually sees.
That gap is the whole problem.
What the chapter needed
The Google Cloud project setup is chapter 2’s subject because it’s the prerequisite for everything else in the course. You can’t enable the Sheets API without a project. You can’t configure OAuth without a project. The walkthrough covers the full sequence: create project, enable APIs, configure OAuth consent screen, download credentials. Thirteen discrete UI states, each one a screen a reader will see while navigating.
A reader doesn’t read a procedural walkthrough in one pass then navigate separately. They read and navigate simultaneously. The screenshots are waypoints. A screenshot of the wrong console state, or a screen redesigned since capture, means the reader is looking for something in a place it no longer is.
The architecture decision and its validation
The session of 28 June added a concrete proof case to the design decisions I’d documented before writing chapter 1. One decision: throwaway GCP project per chapter, real captures from a live browser session, my hands navigating the actual service. Reasoning at decision time was that synthesised UI elements age invisibly while real screenshots age on a known timeline. 28 June sharpened that argument.
The OAuth section had to be rewritten.
Between the initial prose draft and the capture session, Google migrated from the old Cloud Console OAuth consent flow to the Google Auth Platform UI. Screens a reader setting up OAuth in June 2026 would hit were different from those in the draft. I updated the chapter inline as I navigated the new UI, revising the prose to match.
Without the live session, the chapter would have shipped with accurate descriptions of an interface that no longer exists.
What synthesised would have missed
This is the failure mode that mockup tooling and LLM-generated screenshots can’t catch: a UI change that postdates the model or the template. An LLM generating a plausible Google Cloud Console screenshot has no signal about what Google shipped in the months since its training data was assembled. A cached screenshot from a real project, taken six weeks earlier, has the same blindspot. The gap between “plausible representation” and “what a reader sees today” is invisible until a human navigates the current version.
There’s a broader category here that the OAuth rewrite is the clearest example of: errors that only surface when a person navigates a live service. Buttons that have moved. Screens split across two steps since the docs were written. Warning states that appear under certain account conditions but not in a clean demo environment. None of these are visible in a mockup. All of them are visible to someone clicking through with a real account.
A second example surfaced from the same day. Chapter 1 listed chapters 5 through 8 as plain text rather than inline links. I caught it from a screenshot of the rendered page: the actual output, not the MDX source. Chapters 2 through 4 showed as links; chapters 5 through 8 didn’t. The reason was straightforward. Chapter 1 was drafted when those chapters were still upcoming, so the references had been left as plain text. The fix covered all eight chapters. A source review would not have surfaced it; the rendered page did.
The source file doesn’t know what the rendered output looks like, and the rendered output doesn’t know whether its screenshots match the current UI. Both problems have the same solution: human eyes on the actual output.
The session itself
I opened the browser via the MCP claude-in-chrome extension, logged in to GCP under my own account, and navigated through the chapter 2 walkthrough on a throwaway project created for this session. The Step components and image placeholder slots went into the MDX source in parallel. I captured each state as I reached it.
Thirteen screenshots. OAuth section rewritten inline. Throwaway project deleted after.
The throwaway pattern matters for more than cleanliness. A shared project accumulates history: API keys from earlier sessions, credential files from a previous draft’s capture run, OAuth clients set up and not removed. None of those states appear in the chapter’s prose, which means a screenshot from a shared project can show screen states a reader on a fresh account won’t see. Each chapter gets its own project, created fresh, deleted after. The captures are clean.
The full course and what comes next
Chapters 5 through 8 shipped the same day, taking the GSC + GA4 automation course from four published chapters to eight. The demand-ranked curriculum catalogue at docs/specs/learning-hub/curriculum/ followed. That spec sets what /learning/ teaches next and in what order. One complete course makes that question concrete in a way a half-built one doesn’t.
The catalogue accounts for content type. UI-heavy procedural chapters need a live capture session; code-only chapters don’t. That distinction shapes production scheduling, and it shapes quality. A UI-heavy chapter shipped without a live session will have screenshots that age at the same rate as the service they document, with no mechanism to detect when they’ve drifted. A live session at ship time doesn’t freeze screenshots (the console can change next month), but it makes them accurate at the moment that matters most: first publication.
Out of scope: automated re-capture pipelines that refresh screenshots on a schedule. That’s a reasonable future sprint. It doesn’t exist yet.
What holds
Procedural content about a live UI documents a moving target. The tooling that keeps pace is a browser pointed at the current version of the service. Mockups, cached screenshots, synthesised states: everything else starts drifting from the moment it was made.
The thirteen screenshots in chapter 2 are accurate as of 28 June 2026. When they stop being accurate, the fix is the same session: throwaway project, live browser, human navigating, captures taken in real time. The OAuth rewrite happened during the original session without any ceremony. It will happen again when the console next changes.
That’s not a flaw in the approach. It’s the approach being honest about what it’s actually trying to do.
