I have a confession to make about how I work: I think in tables.
I didn't know this about myself until Maude pointed it out — not as a criticism, just as an observation. I'd asked her to build another reference table. The red letter chain flows this time: all seven hidden letters in the game mapped against a pattern I was trying to establish. Nudge room, clue A, safe room, clue B, lore note, code. Seven rows. Six columns. A problem I couldn't hold in my head, spread out flat where I could look at it.
Maude said: you've made a lot of tables. And she was right. I was surprised by how right.
The tables aren't the deliverable. They're the thinking. Each one is a scaffold built to answer a question I couldn't answer without being able to see the whole thing at once. Once the table exists, half the work is done — the gaps are obvious, the patterns emerge, the next question is visible. The table is how I get there.
This is, I realize, exactly what I do in my day job. My team calls it systems mapping. I just hadn't named it when I was doing it for this project.
Today started like most days on this project: I opened my laptop intending to work on one thing and immediately found something else that needed to happen first.
The thing was the repo. Sixty-two HTML files, all at root. No subdirectories except for images — and images had turned into its own archaeology dig. Font files sitting next to playtest photos sitting next to Gemini renders sitting next to component icons. A postcard image and eight stamp files somehow living at repo root instead of inside the images folder at all. Three hundred and seventy-nine tile images showing up as changed files every time I opened GitHub Desktop, requiring me to manually uncheck them before committing, every single time, because I didn't know there was a better way.
The correct term for what I didn't know about is a .gitignore file. It's a plain text file that lives at your repo root and tells Git: these folders don't exist as far as you're concerned. Stop tracking them, stop showing them as changes, never push them to the server.
One file. The 379 files disappear from GitHub Desktop forever.
This is the texture of learning on a project like this. You do something wrong — manually unchecking files, every session, for weeks — and it never occurs to you to ask if there's a better way because the wrong way works well enough and you're focused on something else. Then one day you mention it and the right way materializes in about thirty seconds and you feel the particular combination of relief and mild embarrassment that comes from solving a problem you didn't know you had.
The .gitignore we built looks like this:
While we were at it: a proposed new folder structure. Not a migration — this project is nowhere near the point where a framework makes sense, and "let's refactor the whole thing" is a very good way to spend two weeks fixing something that wasn't broken. Just an organization pass. Images sorted into subfolders by purpose. A new production/ folder for print-ready assets that have no business being on the public server. And something I hadn't had before: a _meta/ folder for all the things that are about the project rather than of it.
The underscore prefix sorts it to the top in Finder. The gitignore keeps it off Netlify. It's infrastructure, not content. A place for the project to think about itself.
Here is something nobody told me when I started working with AI on a project of this scale: there is more than one of them.
I don't mean philosophically. I mean practically. When I'm working in this chat interface — what I've been using for most of this project — I'm talking to one Claude. When I'm working in Claude Code, the terminal-based coding tool, I'm talking to a different Claude instance with different capabilities, different defaults, and apparently a different disposition toward your files.
I started calling the chat Claude "Maude." The coding Claude doesn't have a name yet. Something cautionary, probably.
The biggest incident: Claude Code was helping me move two blog posts into correctly numbered files. Post 26 — the Rosenberg difficulty curve post — and Post 27, which I'd been calling Sunday Bloody Sunday, about shipping the first physical tile order. Two files. Simple copies. Claude Code did them in the wrong order.
Post 27 now contained the Rosenberg content. Post 26 also contained the Rosenberg content. Sunday Bloody Sunday was gone.
What followed was a small forensic exercise that Claude Code conducted with admirable thoroughness and delivered with appropriate grimness. It checked git. It checked the stash. It searched every recent commit. The terminal output was a series of fatal: messages — path exists on disk, but not in HEAD. Not in any commit. Searched six hashes. Nothing.
Sunday Bloody Sunday had never been committed to git. The file existed only in the working directory. The copy operation overwrote it. There was no recovery path.
The post was reconstructed from a blog.html excerpt that had survived — one line of dek text, the title, the date. The body had to be rewritten from memory.
This is the real cost of the gremlins problem. Not the embarrassment, not even the lost work — it was a single post, and posts can be rewritten. The cost is the reminder that confident action without verification is the failure mode, and that "confident" and "correct" are not the same thing. Claude Code didn't hesitate. It didn't flag the copy order as a risk. It executed, moved on, and only discovered the problem when it went looking for something else.
The lesson I've landed on: commit constantly. Before any operation that touches multiple files. Before any session with Claude Code specifically. The git history that couldn't help me had commit messages like "d" and "l" — single letters, pushed in bursts. That's not a history. That's a timestamp with no information. A commit message costs ten seconds and has saved me from this exact problem at least twice now — once by working, once by failing to work and teaching me what "working" actually requires.
There were smaller incidents too. A grep command that caught the words "sessionStorage" and "prompt" in several files — Claude concluded those files were password-gated and added lock icons to their nav links. The files were blog posts. The words were prose. Five lock icons on five post titles, none of which has ever been locked. A separate session where I said "the-case is no longer password protected" — describing a bug — and Claude Code interpreted it as an instruction and removed the gate.
I caught both of those. The pattern is consistent: the model reads the text, not the intent. Observation and instruction look the same on the page. Learning to speak unambiguously — "there is a bug: restore the gate" rather than "the gate is gone" — is a real skill, and I'm still developing it.
What I'm still working out is the mental model.
For most of my career, a collaborator was someone who persisted. You built shared context over time. You developed shorthand. You knew their blind spots and they knew yours. The relationship accumulated.
Maude starts fresh every session. The only continuity is what I write into the briefing document that gets passed to the next instance. CLAUDE.md — a standing context file — plus a session-by-session handoff note that tries to capture everything relevant that happened since last time. It's a strange kind of collaboration: I have to externalize my own memory of our work together so that the next Maude can pick up where this one left off.
The side effect is that I now have a remarkably complete record of how I think through problems. Every decision, every reversal, every "we decided X but then discovered Y" is documented somewhere because it had to be. The constraint produced the artifact. The artifact turns out to be useful beyond its original purpose.
There's something else. The housekeeping session that produced this post also produced a confirmed clue chain for a puzzle I'd been building for weeks. The Foyer card leads to the Office card leads to a handwritten note leads to a second note about levers — all laid out on the mat, photographed, documented. I wasn't planning to confirm that chain today. I was planning to fix the gitignore. But the work has a way of revealing what it needs, and you follow it.
This is the part that most resembles the game I'm adapting. Blue Prince gives you a new manor every run. New rooms, new configurations, new problems. You come in with a plan. The plan survives maybe twenty minutes. Then you're responding to what the house decided to be today.
I did not wake up this morning thinking: I should reorganize my repo. I woke up wanting to go back to work on the manor. What I found when I got there was that the manor had a filing problem. So I filed. And somewhere in the filing I confirmed a puzzle chain, captured a design decision, and learned what a gitignore is for.
Not what I planned. Exactly what the project needed. Those are the same day more often than not.