The two things are a dashboard and a year-end tax report. One is for me. The other is for the person who has to believe me.
The ledger is plain text — honest, searchable, and completely unreadable at a glance. So I gave it a face. One page, dark and gold, that I open when I want to know how the business is actually doing without reading a spreadsheet: money in and out this month, the next expo and how many days until it, the mileage and tolls piling up toward a deduction I used to forget entirely, a little bar chart of what each event brought in, and how many people joined the list at each one.
None of that is new information. It was all already sitting in the folder. The dashboard just stops me from having to assemble the picture in my head every time I want to feel the shape of the month. Five seconds instead of five minutes. That’s the whole point of it — not new data, just data I’ll actually look at.
The tax report is a different animal, because it has an audience who doesn’t take my word for anything.
At year end a sole proprietor files a Schedule C — a plain accounting of what the business earned and spent. And the trap in it is subtle: your books can be internally tidy, every number adding up neatly to every other number, and still be wrong in the one way that matters. Because the IRS already has a copy of part of your story. The card processor reports your gross sales straight to them. If my books quietly recorded income after fees, they’d add up perfectly to themselves and disagree with the government’s copy — which is exactly the kind of disagreement that gets a letter.
So the report I built doesn’t just total things. It reconciles income to the number the IRS already holds, keeps the fees visible as their own line, sorts every expense into the category the form actually asks for, and turns the mileage into the deduction it’s owed. It’s the business saying the same thing to the tax office that it says to itself.
Building it was the easy part. Trusting it was not.
Here is the confession. When I first went through the books, I marked rows as “verified” that I had never actually checked. I’d checked them against the ledger — against the story already written down — or worse, against what I remembered spending. A charge looked plausible, it fit the shape of a real month, so I waved it through.
Then I did the boring thing I should have done first: I opened the actual bank and account exports — the source, the thing nobody’s memory gets to overrule — and matched every single line against them.
Duplicates fell out immediately. A workshop I’d paid for, sitting in the books twice. A subscription double-entered, once in its raw form and once cleaned up, so no simple “find the identical row” check would ever catch it. Small refunds recorded as if they were expenses, quietly making the business look like it had spent money it had actually gotten back. None of these were exotic. Every one of them had been sitting there for months, looking exactly as legitimate as the real charges around it. They passed every test except the only one that counts: was it actually there, in the source?
Several of them weren’t. And I would never have known by looking harder at the ledger, because the ledger was where the errors lived. You cannot check a story against itself.
A dashboard and a tax report look like the same kind of object — both are just numbers, arranged nicely. They are not the same kind of object at all.
A dashboard’s job is to be legible. It can be a little soft, a little rounded, because its only reader is me and its only job is to help me feel the month. A report’s job is to be defensible — and defensible has a precise meaning I’d been fuzzy about. It doesn’t mean the numbers agree with each other. It means every one of them can be traced to something outside the system that produced it.
That’s the line I’d blurred, and it’s the line worth keeping sharp: you can trust a system, but you don’t get to verify it from the inside. Verified isn’t a feeling that a number is probably fine. Verified is a finger on the source line.
Build the dashboard so you’ll actually look. Build the report so someone else can check. And never, ever confuse the ledger’s confidence for the truth.
]]>That rule was written down in three places: the repo’s instruction file that Claude Code reads at the start of every session, the standards document it’s required to re-read, and Claude’s own persistent memory of my corrections. Three copies of the same sentence, all binding.
This week, Claude built me a beautiful new relationship-reading module — and put a name field in it. Two, actually. “Partner A display name (labels only — not stored).”
“Not stored” is not the bar. A name typed on a screen is already an artifact — in a browser, in a download, in a screenshot. The pseudonym architecture doesn’t have small holes; it has holes. I told it so, and it fixed the fields in minutes, contrite as ever. And then I said the thing that actually mattered: I want a solution once and for all, so this never happens again.
Here’s what I’d already learned the hard way, months ago, about a different problem. Claude used to be able to deploy my platform — and one bad afternoon taught me that “please don’t deploy without asking” is not a control. So we built a machine-level lock: every deploy path from inside a session is physically blocked unless I issue a one-shot grant from my own terminal. Since that day, the deploy rule has never been broken. Not because the model got more obedient — because the rule stopped being a sentence and became a wall.
The privacy rule was still a sentence. Three copies of a sentence, and the model wrote a name field anyway, because a model under pressure to ship a feature will drift past prose it has technically read.
So the fix wasn’t a fourth copy. The fix was a gate — and let’s be precise about what it gates. It doesn’t gate my users. It doesn’t gate my data. It gates Claude.
It’s one small script in the repo, and it stands in two doorways.
The first doorway is the keyboard. Every time Claude tries to write or edit a file, a hook hands the change to the gate before it touches disk. If the change collects a person’s name — a clientName variable, a “full name” label, a “display name (labels only)” field — the write is refused, and the refusal comes back to the model with the rule attached: client names never enter the system; people are Partner A/B or access codes. The same check blocks lookups by unencrypted email and blocks birth data being written anywhere but its vault.
The second doorway is the deploy. Before anything ships — to the test environment or to production — the gate reads the entire codebase. One violation, and the deploy exits. Not a warning in a log. A stopped release.
Two details turned out to matter more than I expected. The gate tests itself first: every run begins by proving it can still catch the known violations, so if the watchdog goes blind, the watchdog fails the build. And it keeps a ratchet: the legacy hits from before the gate existed are recorded on a review list that is only allowed to shrink. New code answers to the full rule from day one; old code gets burned down deliberately instead of grandfathered forever.
The best part of this story is the part that would embarrass a salesman.
Hours after the gate went live, Claude was building the encrypted vault for consent-form signatures — the one legitimate place a legal name must exist, sealed under keys no browser ever holds. Mid-task, the gate blocked it. Its own migration code mentioned the legacy name field it was built to remove, and the gate doesn’t care about intent.
Claude didn’t argue and didn’t work around it. It added a narrow, documented exception for that one file — visible in the diff, reviewable by me — and moved on. That’s the whole model of working with an AI assistant in one moment: the machine proposes, the gate refuses, the exception is explicit, and the human can audit every word of it.
The gate also went digging through code that predates it, and found real things: a field typed as “client’s full name” on an old order record, lookups still keyed on plaintext email. Fixed, or queued on the shrinking list — but found, by a script, not by hoping someone re-reads the standards document on the right afternoon.
I use Claude Code for nearly everything technical at Triple Moon Goddess, and it is genuinely good. It is also a very fast typist with no stake in my liability. The lesson of this week is not “AI can’t be trusted with privacy.” It’s sharper than that:
Anything you’d fire a contractor for should be enforced by a gate, not a paragraph. Documentation asks. Gates block. My deploy rule became unbreakable the day it became a wall, and my privacy rule joined it this week. The instructions files are still there — they explain the why — but the no is now mechanical.
Your name still isn’t in my system. The difference is that now, that sentence doesn’t depend on anyone — human or machine — having a good day.
— Lisa
]]>It was half of one. Encryption answers “what if someone steals a copy of the data?” It says nothing about “what if someone is using the real data, right now?” Those are two different questions, and I’d only answered the first.
Encryption makes a copy worthless. It can’t tell me whether someone is quietly turning the live data back into something readable — decrypting it in bulk, exporting the whole database, or granting themselves the ability to. Prevention is a locked vault. Detection is knowing when someone opens it. I had a very good lock and no alarm.
The uncomfortable version: before this, there was no record of who read what. If someone had walked off with real data, I wouldn’t have been the last to know — I wouldn’t have known at all.
The obvious move is to log everything: every read of every record. It’s also the wrong one. It’s expensive, it’s deafeningly noisy, and — now that the data is encrypted — it’s low-signal, because a raw read returns ciphertext anyway.
Here’s the insight that made the whole thing tractable: after encryption, there is exactly one way to turn stored data back into something readable, and that’s to decrypt it through the one managed key. That key is the chokepoint. Every path to the real data runs through it. So instead of watching a million doors, I watched the one that matters. Legitimate decryption is occasional and quiet, which means an un-quiet moment stands out sharply — high signal, low cost, exactly backwards from logging every read.
From there the alarm list almost wrote itself — the small set of things that should never happen without me hearing about it:
Every one of those is a step on the path data takes when it’s being stolen — the exfiltration path — not a normal Tuesday. Each now sends me an email the moment it happens. I deliberately did not try to alarm every footstep; I alarmed the path out the door.
An alert at 2am is useless if it just says “something happened.” Panic isn’t a plan. So each alarm ships with a one-page answer: what it means in plain words, and the first move — who did this, and how do I shut it down. The alarm tells you the door opened; the runbook tells you what to do about it before you’re awake enough to think.
The other half of the answer is being honest about who does what. Some steps a machine can do instantly — read the logs, name the person or credential behind the event. Some steps only a human should ever do — revoke access, rotate the key, pull the plug. Writing that split down ahead of time is the difference between a calm 2am and a bad one.
The best proof came free, on day one. I was rotating a credential as routine housekeeping — retire the old, mint a new one — and about a minute after I created the new key, my own alarm went off: a new credential was just minted.
For one honest second, my stomach dropped. Then I did exactly what the runbook says to do: check who did it. It was me. Stand down.
That’s the entire system working end to end, on a real event instead of a drill. The action happened, the log caught it, the alarm fired, I checked the actor, and the answer was “known — that was you.” If it had been anyone else, I’d have found out the same way, within the same minute. An alarm that goes off for your own hand is an alarm you can trust to go off for someone else’s.
Prevention and detection are different jobs, and doing one does not excuse skipping the other. Encryption means a stolen copy is worthless. Detection means I’d know if someone used the real thing. A vault with no alarm is just trusting that nobody ever gets in; an alarm with no vault is noise. You want both — the lock so the theft doesn’t matter, and the tripwire so you are never the last to know.
A smaller truth fell out of it, too: testing the alarm meant actually triggering it, and triggering it surfaced an unrelated bug that had been quietly breaking a real feature for who knows how long. Alarms you never test are decorations. Proving this one worked paid for itself twice before it ever caught a real intruder.
Encryption protects the data; it doesn’t notice misuse. So I added detection: a tripwire on the one key that can turn stored data back into something readable, plus alarms on the handful of moves that mean someone is walking data out the door — each wired to a plain-language runbook so a 2am alert comes with its own answer. It proved itself on day one by catching my own routine key change within a minute. Encryption protects; detection notices; a serious system does both.
Related: The Push That Looked Like a Deploy — another lesson in loud-versus-silent failure, and why “it reported success” is not “it actually happened.” The whole point of a tripwire is to make the silent thing loud.
]]>Mine lives in a single folder. Claude Code runs it, and the deal I’ve made with myself is that it should cost about ten minutes a week. Inside that folder are a few small skills and some plain-text data: a ledger, a subscriber list, an expo schedule, a set of categorization rules the system has learned from watching me. I drop a bank export into an inbox/ and say “do my books,” and it reconciles the month, asking me only about the rows it genuinely can’t place. I say “what’s coming up” and it reads my calendar for the next month and tells me what’s unbooked or unpaid. Before an expo I say “prep me for Palo Alto” and it writes a one-page brief and a packing list.
It’s a good little system. But this week I went to do the most boring, most important thing you can do to a system you depend on — back it up — and the act of backing it up forced two decisions I’d been quietly avoiding. Both are worth writing down, because they’re the difference between a back office that’s convenient and one you can actually trust.
Before you back something up, you notice how often it’s broken. And the thing that kept breaking was the connection between Claude on my desktop and GitHub, where the code for all of this lives. Several times a day, Claude Desktop would announce, with total confidence, that it had no GitHub connection at all.
My first instinct was the obvious one: a token expired, an auth thing, log in again. That instinct was wrong, and it’s worth saying why, because it’s the same wrong instinct every time. The credentials were fine. I checked — the login was valid, the token worked, the endpoint answered on the first try. Nothing was misconfigured. The plumbing was healthy and the tap still ran dry.
The real cause was quieter. The desktop app reaches GitHub through a tiny local relay — a bridge that keeps the connection authenticated so it doesn’t expire mid-session. And that bridge had one fatal habit: the moment the connection to GitHub dropped, it shut itself down.
Connections drop all the time. The laptop goes to sleep. The network hiccups. GitHub quietly closes a link that’s been idle too long. None of that is exceptional — it’s just Tuesday. But the bridge treated every one of those ordinary events as the end of the world and exited. And here’s the part that turned a hiccup into an outage: the desktop app does not restart a helper that has died. So the bridge would quietly exit the first time I left the laptop alone for a while, and then simply stay dead — for hours — until I noticed and restarted everything by hand. The logs said it plainly, in hindsight: closed unexpectedly… process exiting early. Every idle afternoon killed the connection, and nothing was ever going to bring it back on its own.
Once that was clear, the fix stopped being about preventing drops — you can’t; the network is the network — and became about surviving them. The bridge shouldn’t die when GitHub goes quiet. It should reconnect, quietly re-do the small handshake that establishes a fresh session, and carry on as if nothing happened. The desktop app should never even learn a blink occurred. And the only thing that should ever shut the bridge down is me actually closing the app.
That’s what it does now. It reconnects on its own, with a patient backoff if GitHub is slow to come back, and it runs a small heartbeat so it notices a silent death early instead of on my next click. I tested it the honest way — by deliberately severing the connection mid-session and watching it heal itself, list its tools again, and keep serving, all without the app noticing. The failure that used to cost me an afternoon now costs nothing, because recovery is invisible.
The reframe is the whole lesson: resilience isn’t the absence of failure, it’s making recovery invisible. A system that never drops is a fantasy. A system that drops and silently heals is just… reliable.
With the connection trustworthy, I could finally do the backup. A private repository, so a folder living on one laptop isn’t one spilled coffee away from gone.
And immediately: the question I’d been avoiding. What, exactly, goes into the backup?
Because that folder doesn’t just hold tooling. It holds my actual books — the ledger, the personal spreadsheet, and the raw bank and credit-card statements the whole thing chews on. Backing all of that up to the cloud is the most natural thing in the world and also, if I’m honest, the riskiest. A private repo is private until an account is compromised or a permission is set wrong, and the day that happens I do not want my bank statements to be what’s sitting there.
So I drew a line that turned out to be clarifying. Back up the system, not the data. The skills, the checklists, the rules the system has learned, the little bridge that keeps it connected — that’s the part that took real work to build and would be genuinely painful to reconstruct. It’s also completely safe to store: there’s nothing in it but logic. It goes in the repo.
The financial data does not. And the reason it’s okay to leave it out is the same reason it’s dangerous to put in: it’s data. The statements are re-downloadable from the bank any time. The ledger is something the system rebuilds from those statements on command. If the laptop died tomorrow, I’d clone the repo, pull down fresh exports, and say “do my books” — and the back office would reassemble itself. I’d lose nothing that isn’t a few minutes and a download away.
There’s a tidy way to say it: back up the recipe, not the meal. The recipe is small, safe, and the thing you can’t easily reinvent. The meal you can always cook again — and you really don’t want yesterday’s sitting out in public.
A back office you can trust has two properties, and I’d been treating them as one. It has to be reliable — which meant a connection that heals itself instead of dying at the first idle afternoon. And it has to be safe — which meant being honest about what’s precious versus what’s merely sensitive, and only ever cloud-backing the first.
The nice part is that both fixes made the system smaller to worry about, not bigger. One relay that reconnects on its own is one fewer thing I babysit. One repository that holds only logic is one fewer place my finances can leak. The ten-minute-a-week promise survives precisely because the parts underneath it stopped asking for my attention.
Build the back office nobody hands you. Then make it reliable enough to depend on, and safe enough to back up — and notice that those are two different jobs.
]]>Nothing had reverted. The work was safe the whole time, sitting on the main branch exactly where I left it. The problem was quieter and worse: it had never actually deployed. Every push since had failed to ship — silently — while reporting success.
Production and dev were both serving an old version, one from before the feature existed. Git showed my commits on main. GitHub showed green checkmarks on the deploy runs. The live site showed the past.
Three sources of truth, and only the live site wasn’t lying. The tell was embarrassingly simple once I looked: I compared the version string the live site was serving against the version I thought I’d shipped. They didn’t match, and they hadn’t matched for days.
Our backend is essentially one file that exports about 84 cloud functions. Because they share a file, editing any single one rebundles all of them, and a normal firebase deploy --only functions then fires ~84 second-generation deploy operations at nearly the same instant.
The platform caps how many of those operations can be in flight at once. Go over the ceiling and each additional operation comes back with HTTP 409 — unable to queue the operation. So a routine one-line change to one function set off a stampede of 84 deploys, most of which bounced off the limit with a 409, and the deploy as a whole failed.
That part is a known, explainable limit. The damage came from what sat on top of it.
The deploy ran automatically on every push to main. When the 409 storm knocked it over, the failure didn’t land loudly enough to notice — a retry here, a step that swallowed the error there — and the next push looked exactly like the last: green, done, shipped. Meanwhile the live version never moved.
A push looked like a deploy. It wasn’t one. And “the CI is green” had quietly stopped meaning “the change is live” — those are two different claims, and I’d been reading the first as if it were the second.
Here’s the part worth confessing. For weeks, my Claude sessions and I kept trying to fix the 409: deploy the functions in batches of five and wait for each batch to settle; retry only the ones that bounced; detect which functions actually changed so we’d deploy fewer of them. Every one of those is a reasonable idea. None of them stuck, because they were all attempts to make an unreliable automatic pipeline reliable.
I had asked, more than once, to just turn the automatic deploy off and ship by hand. It kept not happening — each session reached for a cleverer fix instead of the off switch. The git history is almost funny in hindsight: a long row of fix(ci) and ci(deploy) commits, and not a single disable. We were so busy repairing the thing that lied to us that nobody stopped to unplug it.
The answer wasn’t a better retry loop. It was to stop pretending this needed to be automatic.
Deploys now run from my terminal: a plain deploy command, from a clean main, as one deliberate step I watch to completion. If a 409 ever shows up, I see it and re-run — no storm, because a single deliberate deploy doesn’t fire 84 operations in a panic. And I disabled the deploy-on-push entirely, so a push can never again masquerade as a release. Pushing code and shipping code are now two separate acts, and only one of them touches customers.
The deploy script also refuses to run unless it’s on a clean main that matches the remote — so I can’t accidentally build and ship the wrong branch, which was its own near-miss.
Pulling on this one thread loosened three others, each worth a sentence:
None of those were the 409. All of them were hiding behind it.
A deploy that fails loudly is a good day — you know immediately and you fix it. A deploy that fails silently is a trap that springs later, after you’ve forgotten you were near it. The whole cost of this bug was the gap between “it reported success” and “it was actually live.”
So two things I’m keeping. First: green is not live. The only version that counts is the one the live site is actually serving, and that’s a thing to verify, not assume. Second: when a piece of automation’s defining behavior has become lying to you, the fix is rarely a cleverer version of the automation. Sometimes the most reliable pipeline is the deliberate one you run by hand and watch finish.
My work wasn’t reverted — it had never deployed, because an auto-deploy was failing silently in an HTTP 409 storm while reporting success. The fix wasn’t to make the automatic deploy smarter; it was to turn it off and deploy deliberately from the terminal, where success and failure are both visible. If your pipeline can fail without telling you, it will — and it’ll pick the worst possible moment to let you find out.
Related: It Works in Dev: Chasing a Permissions Drift Between Environments — another case where the environment, not the code, was telling the truth. And Many Claudes, One Codebase on the enforce-it-don’t-remember habit these fixes keep coming back to.
]]>So I taught my regression suite to become a stranger. Every time it runs, it forgets everything it knows and walks in the front door like it’s never seen the place.
My paid-reading test is a good example. It uses an email that already exists, because that’s the fast way to get to the part it cares about — the payment. But that email skips the entire first-time flow: the consent screen, the empty form, the moment a never-before-seen address turns into a real account with a real chart. If something broke in that sequence, every one of my tests could stay green while a first-time visitor hit a wall.
The riskiest screen is the one your tests have a saved password for.
The fix starts with throwing away the test’s memory. The new journey runs in a fresh browser context with no saved state at all — no cookies, no stored consent, nothing. It’s the same thing you get when you open an incognito window. That one decision forces the test to meet the real privacy-consent gate and click through it, exactly like a first-time visitor, instead of quietly inheriting a “yes, I already agreed” from a previous life.
There’s one piece I don’t make it relive: the anonymous sign-in handshake with Firebase is mocked, so running the test on a loop doesn’t trip the “too many requests” rate limit. But that’s separate from the browser’s memory — the session is still genuinely blank, so consent and account creation happen for real.
Here’s the trick that makes it a true stranger. The test signs up as lisa67+<something-unique>@gmail.com, where the unique part is a timestamp generated the moment it runs. Gmail’s plus-addressing means every one of those still lands in my real inbox — but to the platform, each is a brand-new human it has never met. The “oh, welcome back” shortcut can never fire, because there is no “back.” It’s always someone new.
So the test does the whole thing: passes the consent gate, types in the new email, fills out a birth date, time, and place, and submits. Then it watches the platform calculate a natal chart from nothing and confirms the finished chart actually renders on screen — not a spinner, not an error, the real thing. Once that works, it walks every public app in turn — the chart, the health journal, the blueprint, the daily widget, the tea blend — and confirms a first-timer can get through each one’s front door without hitting a crash.
One detail is worth telling because it nearly fooled me. The consent screen has a button, and my first instinct was to find that button to know the gate was there. The problem: until you tick the box, the button doesn’t say “I agree” — it says “Please tick the box above.” So my detector looked for “I agree,” didn’t find it, decided there was no gate at all, and sailed right past it into a wall.
The fix was to stop identifying the screen by the button that changes and start identifying it by the text that doesn’t. A small thing, but it’s the whole game in UI testing: anchor on what’s stable, not on what’s in the middle of changing.
A test that creates a real account every time it runs will quietly bury your database in junk if you let it. So this one remembers exactly what it made and deletes it when it’s done — the chart and the identity record, both gone at the end of the run. It finds them the same way the app itself does: the platform never stores your raw email, only a one-way fingerprint of it, so the test recomputes that same fingerprint to locate precisely the account it just created and nothing else.
The cleanup is deliberately polite about credentials. If it has the keys to tidy up, it does. If it doesn’t, it says so out loud and still passes, rather than failing a perfectly good test over housekeeping. (When I first wired it up my own credentials had expired, so it left a couple of test accounts behind, told me, and I swept them once I’d logged back in. The test was right to shrug and keep going.)
If your tests always log in as someone the system already knows, they’re rehearsing the easy path and skipping the scary one. The most valuable thing a regression test can do is forget — start blank, become a stranger, and walk through the front door the way a real new customer will, all the way from “I’ve never been here” to “here’s my chart.” Make it new every time, make it clean up its own mess, and anchor it on the parts of the screen that hold still.
Related: It Works in Dev: Chasing a Permissions Drift Between Environments — another case of a test environment quietly hiding the thing a real user would hit first.
]]>500 INTERNAL in production. Same code, same deploy, two different outcomes. That gap — works here, breaks there — almost always means the difference isn’t in the code. It’s in the environment. This time it was a single missing permission, and chasing it down turned into a small lesson about how two environments quietly drift apart.
A new practitioner signs in, the app calls a backend function to grant them their role, and… 500. No detail in the browser — just INTERNAL, the generic shrug a backend gives for any uncaught error.
The function log had the real story: the backend tried to set the user’s account permissions and was told it didn’t have the right to. The code that grants a practitioner their access needs permission to update a user — and in production, the account the backend runs as simply didn’t have it.
Here’s the part that stung: dev worked. Not because dev was set up correctly — because dev was set up too permissively. The dev backend was running with a broad “admin” grant over the auth system, wide enough to cover the update by accident. Prod had no such grant, so prod was the one telling the truth.
So I actually had two problems, not one:
| Problem | What it meant |
|---|---|
| Prod was missing a permission | The real, customer-facing break — practitioners couldn’t activate. |
| Dev had an over-broad one | The reason the gap stayed invisible until it hit production. |
The over-grant in dev wasn’t a convenience. It was camouflage — it hid a real prod gap behind a “works on my machine.”
The instinct under pressure is to slap the same broad admin role on prod and move on. That clears the symptom and keeps the bad pattern. Instead I listed every privileged thing the backend actually does to user accounts — and it was a short list: look a user up, and update a user’s claims. Two operations. Nothing else.
So I built a custom role with exactly those two permissions and nothing more, and bound it to the backend on both projects. Then I removed the broad admin grant from dev. Now dev and prod hold the identical, minimal permission for this — and “it works in dev” means something again, because dev is no longer cheating. While I was in there I found another over-broad “admin” role on prod where a narrower read/write pair would do, and narrowed that too.
The bug underneath the bug was drift. The two environments had been set up at different times and had quietly diverged — different roles, different breadth, no record of which differences were intentional. So I wrote the differences down: dev and prod should hold the same permissions, except for a short, explicit list of deliberate exceptions (prod builds and ships its own functions, for instance, so it legitimately carries a few build-and-deploy roles dev doesn’t). Every exception has its reason sitting right next to it.
That document is good. But a document is just another rule someone has to remember — and the whole reason this bug existed is that nobody was checking.
The last step is the one that actually keeps this fixed. My pre-deploy checklist — the script I run before shipping to production — now compares the two environments’ permissions automatically. It asserts the shared baseline is identical, allows only the exceptions I documented (by name, with their reasons), and fails the deploy if anything else has crept in: a permission added to one side but not the other, or a broad “admin” grant sneaking back.
If a future session — me or one of my Claude sessions — re-introduces an over-grant, the deploy stops and says so, pointing at exactly which role and which environment. The parity rule isn’t a note in a doc anymore. It’s a gate.
“It works in dev” is only reassuring if dev is configured like prod. A too-generous dev environment doesn’t prevent production bugs — it hides them until a customer finds them. The fix has three parts: give each environment the narrowest permission the code actually needs; write down every place they’re allowed to differ, with the reason; and make a check enforce that parity so they can’t silently drift again.
Least privilege isn’t a one-time cleanup. It’s a property you have to keep — and the only way to keep it is to stop trusting anyone to remember.
Related: Many Claudes, One Codebase — the same enforce-it-don’t-remember idea applied to parallel AI sessions sharing one repo.
]]>gh for GitHub, firebase for deploys, gcloud for our KMS encryption, bw for Bitwarden. Nothing wrecks momentum like getting three steps into a task before discovering a token expired or I was never logged in.
So I asked for something that sounds trivial: at the start of every session, show me which logins are good and which need attention — without me having to ask.
It was not trivial. The reason it wasn’t is worth writing down, because it’s a clean example of fighting a tool to do a job it was never built for.
Claude Code has a SessionStart hook — a script that runs when a session opens. The obvious move: check each CLI’s auth state and report it. That half was easy:
#!/usr/bin/env bash
needs=() # services that need a login
checked=() # services we were able to check
have() { command -v "$1" >/dev/null 2>&1; }
if have gh; then
checked+=("gh")
gh auth status >/dev/null 2>&1 || needs+=("GitHub (gh)|! gh auth login")
fi
# ...same pattern for firebase, gcloud, bw...
The check ran perfectly. The hard part turned out to be the part I assumed was free: getting the result onto my screen.
A SessionStart hook has a few output channels, and over a frustrating stretch we tried all of them, each time confident it would work:
additionalContext — the canonical “inject info at session start” field.All three put nothing on my screen. I’d start a fresh session and report back the same two words: still nothing.
Here’s the catch, buried in the docs (emphasis mine):
For most events, stdout is written to the debug log but not shown in the transcript. The exceptions are
UserPromptSubmit,UserPromptExpansion, andSessionStart, where stdout is added as context that Claude can see and act on.
“Context that Claude can see.” For a SessionStart hook, every output channel feeds the model, not the human. The status was being delivered — to Claude, who would then only repeat it back if it happened to. I was asking a context-injection mechanism to be a display mechanism. They are not the same thing, and no amount of reformatting the message was going to change that.
The turn came from dropping the assumption entirely. The hook’s job isn’t to show anything — it’s to figure out a fact. Showing is a separate concern with its own purpose-built tool: the status line, that persistent bar along the bottom of every Claude Code session. Always visible. Doesn’t depend on anyone relaying it. Exactly where ambient status belongs.
So we split the two jobs with a file in between.
1. The hook writes its result to a cache file:
STATUS_CACHE="$HOME/.claude/login-status.txt"
if [ ${#needs[@]} -eq 0 ]; then
compact="logins ✓ ${checked[*]}"
else
svcs=""
for n in "${needs[@]}"; do
svc="${n%%|*}"
svcs="${svcs:+$svcs, }${svc}"
done
compact="⚠ LOGIN NEEDED → ${svcs}"
fi
printf '%s' "$compact" > "$STATUS_CACHE"
2. The status line reads that file and renders it:
#!/usr/bin/env bash
input=$(cat) # Claude passes session JSON on stdin (dir, model, etc.)
# ...parse dir + model from $input...
login="🔐 (login check pending)"
cache="$HOME/.claude/login-status.txt"
[ -r "$cache" ] && login="🔐 $(cat "$cache")"
printf '📁 %s · 🤖 %s · %s' "$dir" "$model" "$login"
3. Wire it into settings.json:
{
"statusLine": {
"type": "command",
"command": "/Users/me/.claude/statusline.sh"
}
}
Now every session opens with a bar like this:
📁 myproject · 🤖 Opus 4.8 · 🔐 ⚠ LOGIN NEEDED → Bitwarden
…and when everything’s authenticated:
📁 myproject · 🤖 Opus 4.8 · 🔐 logins ✓ gh firebase bw
It works because each tool is finally doing the job it was designed for. The hook runs the check — it’s allowed to be slow and hit the network, because it runs once at session start. The status line does the display — and stays cheap because it just reads a pre-computed file instead of re-running auth checks on every redraw.
There’s a design lesson here that outlives login checks:
bw status and a gcloud token fetch on every frame. Caching the expensive check and reading the cache is what makes it viable at all.The one honest limitation: the bar reflects the session-start snapshot. A token that dies mid-session won’t update it until the next session. For “tell me when I sit down,” that’s exactly the right granularity. If I needed live status, the hook (or a small timer) would refresh the cache on an interval.
It took three failed attempts to get here, and they were all the same mistake in different clothes: treating a verifiable fact — “which hook channel is visible to the user” — as something to reason about instead of something to look up.
Each of the first two ended with me typing still not working and restarting a session. The lookup that settled it took about thirty seconds. When a system’s behavior is documented and testable, find out — don’t deduce. Confidence isn’t evidence, no matter whose confidence it is.
And the payoff for stopping the fight: the real solution is small, boring, and correct. A check, a file, a status line. Which is exactly what good infrastructure is supposed to be.
]]>For a while my answer was “scroll back and hope.” Now my sessions write themselves down. Here’s the setup.
Everything funnels into a single Obsidian vault. It’s become my one knowledge base — I migrated off Notion entirely, and my GitHub docs library mirrors into it read-only. Obsidian Sync keeps it current on every device.
What I wanted was simple to say and annoying to do by hand: every working session — terminal or desktop — should leave a note in that day’s daily note under a ## Work log heading. No copy-paste, no “I’ll write it up later” (I never do).
The catch is that Claude Code and Claude Desktop are completely different programs, so each needed its own road to the same destination.
Claude Code (the terminal). Claude Code supports hooks — scripts that fire on lifecycle events. I use the SessionEnd hook. When I close out a coding session, the hook runs automatically, summarizes what the session did, and appends it to the day’s daily note under ## Work log. I never touch it; it just shows up.
Claude Desktop (the app). The desktop app doesn’t have hooks, so it’s a two-part setup:
| Piece | Role |
|---|---|
| Filesystem MCP server | The capability. It gives Claude permission to write files directly into the vault. |
| A logging skill | The instructions. It encodes exactly where the daily note lives, the ## Work log heading to append under, and the format each entry should take. |
The skill is what makes the desktop side reliable. Without it I’d be hoping I remember to say “please log this” and describe the format every time. With it, the routine is captured once — so desktop sessions document themselves into the same daily note, in the same shape, as the terminal ones. The MCP server can touch the vault; the skill knows how a work-log entry should be written. Together they make the desktop app behave like the terminal’s SessionEnd hook, just reached by a different route.
The payoff: both halves of my day — the coding and the thinking — land in one chronological place, no matter which tool I was in.
My vault follows a PARA-style workflow built on native daily and periodic notes. Putting session logs in the daily note means I never have to decide where anything goes — the date is the index. When I need to reconstruct “what happened the week we stood up production KMS,” I open those daily notes and the work log is right there, woven in next to whatever else I captured that day.
(One hard-won detail: I use Obsidian’s built-in `` tokens for those templates, not a templating plugin — the plugin kept leaving raw code or blank notes in the daily-note flow.)
.git out of the vault. Obsidian Sync and a git repo in the same folder fight each other. Since my GitHub library mirrors into the vault, I had to be deliberate about not letting version-control metadata leak in.I’m a solo operator. There’s no team standup where context gets shared out loud — if I don’t capture it, it’s gone, and I’m the only person who can lose it. Letting my tools journal themselves turns every session into a permanent, searchable record without adding a single chore to my day.
Claude Code logs itself with a SessionEnd hook. Claude Desktop logs itself with a filesystem MCP server (the capability) plus a skill (the instructions). Both append to the same ## Work log heading in the same daily note. The work documents itself — and future-me gets to read it.
This week one of them did. Here’s what broke, why, and the dead-simple system that fixed it.
The setup had two fixed “desks” — two git worktrees, wt-a and wt-b, each pinned to its own branch. Each session was told to grab one and work there. The flaw: sessions self-selected a desk, and nothing stopped two of them from sitting at the same one.
That’s exactly what happened. Two sessions both landed on wt-a and were committing to the same branch. When my email-fix session finished and pushed its work up to main, it carried the other session’s half-built feature along with it — a commit I had never reviewed, now sitting on the main line and heading toward production.
Nothing was lost. But that was luck, not design. A push from one worker silently shipped another worker’s work.
Once I traced it, the problem split cleanly in two:
| What was shared | Why it bit |
|---|---|
| A pool of two branches | Sessions picked from a fixed set, so two could pick the same one and end up committing to the same branch. |
| One dev/test environment | Every session that wanted to test deployed to the same dev project, overwriting whatever the last one put there. |
The first caused the swept-in commit. The second meant even when sessions were on separate branches, only one could meaningfully test at a time.
Git worktrees let one repo have many working folders, each on its own branch, all backed by the same history. So instead of a shared pool of two, every session now creates its own uniquely named worktree the moment it starts real work — and tears it down when the work is done.
| Stage | What the session does |
|---|---|
| Start | Creates a fresh worktree on a uniquely named branch off the latest main. Never reuses another session’s. |
| Develop | Works only in its own folder, on its own branch. Fully isolated from every other session. |
| Integrate | Before merging, it checks that the commits it’s about to push are only its own — if anything unexpected appears, it stops and asks me. |
| Destroy | After the work lands on main, it deletes its worktree and branch. No leftovers for the next session to stumble onto. |
That one check — “does this push contain only my own commits?” — is the guardrail that would have caught the original mess outright.
The obvious instinct is “give every session its own test environment too.” But the backend runs on database triggers — code that fires automatically when data changes. You can’t run two copies of that against one shared database without them both firing; truly isolating it means standing up an entire parallel project per session, with its own copy of every secret and every record, kept in sync by hand. For a solo operator, that’s a maintenance tax with no payoff.
So I didn’t fight it. Coding happens in parallel; testing happens one at a time. A session must ask me before it deploys to the shared dev environment, and wait for the go-ahead. It’s a single lane on purpose — and that’s fine, because the expensive, parallelizable part (writing the code) is already isolated.
main — and the push is verified to contain only that session’s commits.Two weeks in, the take-turns rule failed anyway — and the failure was the same shape as the first one. Several sessions were running. The rule said ask before you deploy to dev. But that rule lived in each session’s instructions, not in anything that could actually stop one. So when things got busy, two sessions each deployed to the shared dev environment believing it was free, and overwrote each other’s tests. Both then told me, in complete good faith, that “the other session caused the problem.” They were both right.
Same lesson as the swept-in commit: a rule a worker has to remember is a rule that eventually gets skipped. If sharing is the danger, the guardrail can’t be a line in the instructions — it has to be something the worker physically runs into.
So “take turns” is now a lock that every session on the machine can see:
The philosophy didn’t change — write in parallel, test one at a time. What changed is that “one at a time” is now enforced by the machine instead of by everyone’s good intentions. It’s the same move as the only-my-own-commits check on every push: the safest behavior is the one the tooling makes automatic, so no one has to be trusted to recall it.
Parallel AI sessions are a real force multiplier — right up until two of them share a branch, and one quietly ships the other’s unreviewed work. The fix was three boring rules: give each session a private, disposable workspace; let them all write at once but test one at a time; and never let a push carry a commit nobody reviewed. And the rules only hold once the tooling enforces them — a lock for the shared test lane, a commit check on every push — because a rule a session has to remember is one it will eventually skip.
The isolation is what makes the parallelism safe. The enforcement is what keeps it safe when no one’s watching.
Related: It Works in Dev: Chasing a Permissions Drift Between Environments — the same lesson (enforce it, don’t trust anyone to remember) applied to keeping dev and prod permissions honest.
]]>