标签：#claudecode

Every idea gets run through a one-sentence test before it is allowed to count as a real idea at all Most ideas die for one of three specific reasons, not vague lack of enthusiasm An idea only earns a build slot once it has survived contact with a real, repeated problem A maybe-later list holds the rest on purpose, and I check it far less often than people assume The One-Sentence Test I Run Before Anything Becomes an Idea I get more ideas than I could ever build. That is not a boast, it is a liability if I do not manage it, because every one of those ideas feels exciting for about twenty minutes, and excitement is a terrible filter for what is actually worth my evenings. So before an idea is allowed to sit on any kind of list, it has to pass one test: can I describe the smallest useful version of it in a single sentence, with no "and" in the middle. That sounds small, but it kills more ideas than any other step in the process. "A tool that tracks my Claude usage and also shows analytics and also has a community feature" does not pass. "A tool that warns me before I hit my usage limit" passes. The first sentence is a pitch for a platform. The second sentence is a pitch for a Tuesday evening. I want the second kind, because the second kind is the one I actually finish. I did not always work this way. Early on, an idea earned space on my list the moment it sounded interesting, and my list grew into a graveyard of half-described plans that all needed a paragraph to explain. A paragraph is a warning sign now, not a feature. If I need more than one sentence to say what the smallest version does, the idea has not actually taken shape yet, it has just acquired enthusiasm, and those are different things. The test also forces honesty about scope early, before I have sunk any real time into something. An idea that needs "and" is usually two or three ideas wearing a trenchcoat, and pulling them apart at the sentence stage is far cheaper than pulling them apart three weeks into a

This is a continuation of my "Claude Code environment" series. In the previous post, Automatically thinning conversation logs to prevent bloat , I introduced the basic pattern for scheduled launchd jobs. This time I'm using that same mechanism to automatically maintain a list of the custom agents in ~/.claude/agents/ . Dropping a single .md file into ~/.claude/agents/ adds a custom agent, but before long you lose track of how many you have, what model each one uses, and which tools each is allowed to touch. That's exactly what happened to me with the 27 agents I now have. I tried writing an INDEX.md by hand to manage them, and of course within a few days it had drifted from reality. The problem: the index rots Manually updating INDEX.md every time you add a custom agent is not sustainable. You forget you added one and leave it out You change a model later and never reflect it in INDEX.md You typo a name or description and never notice I concluded there was no sustainable way to manage this other than "generate it automatically," so I wrote agents-index.sh . The output: a real INDEX.md Here's how the top of my current ~/.claude/agents/INDEX.md looks. <!-- AUTO-GENERATED by ~/.claude/scripts/agents-index.sh — DO NOT EDIT MANUALLY --> # Agents Index (27 agents · 2026-07-28 02:02) | Name | Model | Description | Tools | |------|-------|-------------|-------| | `architect` ( [ architect.md ]( ./architect.md ) ) | opus | Software architecture specialist ... | ["Read", "Grep", "Glob"] | | `build-error-resolver` ( [ build-error-resolver.md ]( ./build-error-resolver.md ) ) | sonnet | Build and TypeScript error resolution specialist ... | ["Read", "Write", "Edit", "Bash", "Grep", "Glob"] | | `doc-updater` ( [ doc-updater.md ]( ./doc-updater.md ) ) | haiku | Documentation and codemap specialist ... | ["Read", "Edit", "Bash", "Grep", "Glob"] | Four columns: Name, Model, Description, and Tools. You can see at a glance how the models break down across opus / sonnet / haiku , and i

Like a lot of you I hit the 5-hour cap most days. What actually annoyed me was realizing the weekly limit doesn't line up with that. Even capping out daily, I ended every week with quota unused. It expires overnight even after I paid for it. So I built claude-overnight . I queue questions during the day, /queue how do sqlite WAL checkpoints work? right inside Claude Code, and a scheduler runs them at night once my limits reset, through claude -p on the subscription. Morning brings markdown reports and a digest of what ran and what happened. Every job saves its claude session, so overnight resume <id> reopens the conversation that wrote the report. You can argue with it about its conclusions over coffee. Or overnight followup <id> "go deeper on X" and it continues tomorrow night. Coding tasks work too. They run in a throwaway git worktree on an overnight/* branch, only against repos I've explicitly trusted, so the agent never touches my working tree. Morning review is just git diff main..overnight/whatever . Since people will ask how it reads limits when there's no official API: Claude Code stores an OAuth token locally (Keychain on Mac, ~/.claude/.credentials.json elsewhere), and GET https://api.anthropic.com/api/oauth/usage with that token plus an anthropic-beta: oauth-2025-04-20 header returns your 5h and weekly utilization with reset times. Same trick the menubar trackers use. It's undocumented and the response shape already changed once while I was building this, so the tool survives without it. The design constraint I cared most about: don't eat my own morning quota. It won't start above 20% of the 5h window, stops at 60%, skips entirely past 80% weekly, rechecks between jobs. In the morning it opens a page in the browser with the whole batch on it — what ran, how long it took, the resume command for each one, and every report rendered inline so you're not clicking through files half-awake. Check it out at https://github.com/rohanprichard/claude-overnight Curio

The question that started this We run Claude Code against a fairly large, fairly automated repository — a farming-assistance platform with a Node.js backend, a Flutter app, a React dashboard, an in-progress Spring Boot microservices migration, and a home-grown "repo memory" layer called gps that captures invariants, lessons, and preferences across sessions. Over several months we'd wired up a lot of automation: session-start hooks, prompt-submit hooks, auto-captured preferences, persona plugins, a mandatory agent-dispatch table. It felt sophisticated. It also felt, some days, slow to get going — every session seemed to start with a wall of text before any real work happened. So when Anthropic published "The New Rules of Context Engineering for Claude 5 Generation Models" , we asked the obvious question: are we actually following our own advice, or have we just accumulated automation that looks like good practice? This post is the audit, the root cause we found, and the fix — including a mistake we made mid-fix that's worth telling on ourselves for. What the blog post actually says Stripped of marketing language, the post boils down to five concrete rules: Keep CLAUDE.md lightweight. Describe gotchas and non-obvious patterns, not everything you know about the repo. Organize by relevance, not comprehensiveness. Progressive disclosure. Load context at the right time — skills, references, and detail should be pulled in when needed, not front-loaded into every session regardless of task. Trust the model's judgment. Remove redundant guardrails and standing instructions that the newer models don't need spelled out every time. Rely on automatic memory, not manual dumps. Don't hand-maintain a giant preferences block in a markdown file — let the memory system surface the right thing at the right time. Design tools and interfaces, not prose. Push instructions into tool schemas and parameter design rather than repeating them in the system prompt. None of this is radical. It's t

Opus 5 runs at 5 and 25 per million tokens against Fable 5 at 10 and 50, so the top tier now costs double for a much smaller gap Thinking is on by default on Opus 5, which silently changes what a tight max_tokens setting does to your output Disabling thinking now returns an error above high effort, so any xhigh or max route that turns it off needs an audit before you migrate Prompt caching starts at 512 tokens on Opus 5, half the Opus 4.8 floor, so short reusable prompts cache with no code change In June I worked through whether Claude Fable 5 was worth double the price of Opus 4.8 and concluded that it usually was, for hard work. Claude Opus 5 landed on July 24 at Opus 4.8's exact price and closed most of that gap. So the answer changed, and a few of the changes will throw errors in code that worked last week. The Price Gap Held, the Capability Gap Closed Opus 5 costs 5 and 25 per million tokens, input and output. That is identical to Opus 4.8 and exactly half of Fable 5 at 10 and 50. Anthropic did not raise the sticker price on the tier it improved, which is the single most consequential fact in this release. What that buys, on the numbers: 79.2 percent on SWE-bench Pro against Fable 5's 80.3, and a CursorBench 3.2 result Anthropic describes as landing within 0.5 percent of Fable 5's peak at max effort, at half the cost per task. On OSWorld 2.0 it goes past Fable 5's best computer-use result at just over a third of the cost. A 1.1 point deficit on the headline coding row, for half the money. Last month the equivalent comparison had an 11 point spread. That is what actually changed, and it flips the default: Fable 5 used to be the reasonable choice for anything hard, and now it has to argue for itself on each task. There is a quieter cost lever too. The minimum cacheable prompt on Opus 5 is 512 tokens, down from 1024 on Opus 4.8. Prompts I had written off as too short to cache now create entries with no code change at all. If you run a lot of small repeated calls,

Three labs shipped flagship models in fifteen days: GPT-5.6 Sol on July 9, Kimi K3 on July 16, Claude Opus 5 on July 24 Opus 5 leads SWE-bench Pro 79.2 to 64.6 over Sol, and ARC-AGI-3 30.2 to 7.8 Sol holds Terminal-Bench 2.1 at 91.9 percent in its top mode and still takes DeepSWE 1.1 and HealthBench Professional Kimi K3 is a 2.8 trillion parameter open-weight model at 3 and 15 per million tokens, roughly 40 percent under Opus 5 on input Fifteen days. That is the gap between OpenAI making GPT-5.6 Sol generally available and Anthropic shipping Claude Opus 5, with Moonshot dropping a 2.8 trillion parameter open-weight model in the middle of it. I wrote a frontier check like this in June and most of it is already out of date, so here is where the three current flagships actually stand. Three Flagships in Fifteen Days Model Lab GA Context Per million (in / out) GPT-5.6 Sol OpenAI 2026-07-09 1.05M 5 / 30 Kimi K3 Moonshot AI 2026-07-16 1M 3 / 15 Claude Opus 5 Anthropic 2026-07-24 1M 5 / 25 The specs have converged to the point where they barely differentiate anything. All three sit at or just above a million tokens of context. All three cap output around 128k. The input prices are within a factor of two of each other. Two years ago a context window was a headline; now it is table stakes, and the interesting differences have moved entirely into behavior under load. Two timing details that get flattened in the coverage. GPT-5.6 Sol was previewed on June 26 and only became generally available on July 9, so some of the earliest benchmark tables were run against a preview build. And Sol is the top of a three-model family alongside Terra and Luna, spanning roughly 1 to 30 per million tokens depending on tier. Comparing Opus 5 to "GPT-5.6" without saying which one is close to meaningless, which is a large share of the comparisons currently circulating. One structural note on Kimi K3, because the parameter count gets quoted carelessly. It is a mixture-of-experts model with 896 exp

Opus 5 posts 79.2 percent on SWE-bench Pro against Opus 4.8 at 69.2, a 10 point jump with no change in per-token price Anthropic published most gains as ratios (three times ARC-AGI-3, more than double Frontier-Bench) rather than absolute scores On CursorBench 3.2 at max effort it lands within 0.5 percent of Fable 5's peak at half the cost per task Public GDPval-AA figures disagree across sources by up to 117 Elo, so I left that row out entirely Anthropic shipped Claude Opus 5 on July 24, and the coverage filled up with ratios instead of scores. Three times the next-best model. More than double the previous Opus. Just over a third of the cost. I went looking for the actual numbers behind those phrases. What I found says as much about how model launches get reported as it does about the model. The Numbers That Are Actually Comparable The cleanest row is SWE-bench Pro, which runs a model against real GitHub issues and checks whether the patch passes the repository's own tests. It is harder than the older SWE-bench Verified set and it is the row the whole industry now quotes. Model SWE-bench Pro Released Claude Fable 5 80.3 2026-06-09 Claude Opus 5 79.2 2026-07-24 Claude Opus 4.8 69.2 2026-05-29 GPT-5.6 Sol 64.6 2026-07-09 That is a 10 point jump from Opus 4.8 to Opus 5 inside two months, and the per-token price did not move (both tiers run at 5 and 25 per million tokens). Fable 5 keeps a 1.1 point lead and charges double for it. Those two facts together are the actual story of this release, and neither one is a ratio. On SWE-bench Verified, the older and easier set, Opus 5 reports 96.0 percent averaged over five trials. The averaging matters. A single run on a set that saturated above 90 percent tells you very little, because the spread between runs starts to rival the gap between models. Five trials is better practice than most launch tables bother with, and it is worth noticing when a lab does it. It is worth being precise about why those two rows behave differently,

I have shipped five small tools this year instead of one big product, Git Dojo, OhNine, Statusline Builder, Claude Blueprint, and RAXXO Studio Each tool solves exactly one problem and stops there, no feature creep, no internal roadmap fights Shipping small forces me to finish things, a habit a single sprawling product lets me avoid indefinitely The pattern only holds because every tool has to earn its own attention, nothing rides on the others The Big Product I Never Shipped For a long stretch, I was building one big thing. Not a specific product I can point to and describe, more a habit of scope. Every idea got folded into the same growing plan, another tab, another settings panel, another "while I'm in there" addition. It felt productive because I was always working on something. It was not productive, because nothing ever crossed the finish line. A plan that keeps absorbing new ideas is not a plan, it is a place where finished work goes to become unfinished work again. The turn came when I noticed how differently I treated small, contained pieces of work. When I sat down to fix one specific annoyance, something with a clear edge around it, I finished. When I sat down to "work on the platform," I drifted. The difference was not effort or time, it was shape. A bounded problem has a visible end. An unbounded one does not, so there is always a reason to keep going instead of stopping and calling it done. That observation is the entire reason Git Dojo, OhNine, Statusline Builder, Claude Blueprint, and RAXXO Studio exist as five separate things instead of five tabs inside one dashboard. Each one started as an itch I could describe in a single sentence. OhNine started as "I want a warning before I hit my Claude limit, not after." Statusline Builder started as "configuring a statusline should not require editing JSON by hand." Git Dojo started as "I want to practice real git commands somewhere the mistakes cost nothing." None of those sentences needed a second paragraph

Anthropic shipped Claude Opus 5 on July 24, calling it a step-change over Opus 4.8, not a routine bump The model runs a 1M token context window as both default and maximum, 128k max output tokens, with thinking on by default Anthropic says it approaches Fable 5 intelligence at roughly half the price, with per-token pricing unchanged from Opus 4.8 It shipped everywhere at once, the Claude API, AWS, Google Cloud, and Microsoft Foundry, and is now the default Opus model in Claude Code What Anthropic Actually Shipped On July 24, Anthropic released Claude Opus 5, and the framing in its own documentation is unusually direct about what kind of release this is. Anthropic calls it a step-change improvement over Claude Opus 4.8, not an incremental one, and says the largest gains land in deep reasoning, agentic coding and long-horizon tasks, and test-time compute scaling. That is a specific claim, not marketing language, and it matches how the model is positioned everywhere else in the announcement: as a model built to stay on task across long tool-use loops rather than one built to win a single benchmark screenshot. The capability list is long and mostly practical. Anthropic highlights better code review and bug-finding, with a high hit rate on real bugs and few false positives, holding up even at lower effort levels. It highlights vision improvements, reading charts, documents, and diagrams, and replicating UI and frontend visuals when the model has tools to crop and check its own work. It highlights office and document tasks, generating multi-sheet spreadsheets with real formulas and structured slide decks, and multi-agent coordination, running teams of subagents with writer-verifier patterns and fewer cases of agents stepping on each other's output. What stands out is that this is not a model pitched as a smarter chat assistant. Every capability on the list points at the same audience: people running Claude inside an agent loop, a coding session, or a multi-step workflow,

Your Claude Code setup doesn't break in one dramatic moment — it degrades a few bytes at a time, and by the time you notice, you've been paying a context tax for weeks. In a previous post I covered running an unattended daily health check with launchd. This one is the follow-up: a three-layer loop that detects that quiet degradation weekly and hands the repair job to claude -p itself. The problem: environments rot quietly if you leave them alone Some things in a Claude Code environment grow just from doing your normal work. ~/.claude/rules/ and MEMORY.md keep getting appended to, until context injection quietly crosses 40KB Experimental agent definition .md files never get archived, leaving dozens to nearly a hundred files under ~/.claude/agents/ permanently loaded Stop hooks fire over and over, creating a hook spam condition Frustration-signaling words pile up in conversation logs and nobody notices A performance audit on 2026-07-11 revealed that "agents I thought I'd archived were still being injected — 99 of them," and that turned out to be the main cause of the degraded experience. That led to the question "so do I have to go check this every week myself?" — and the answer was to automate it , which is what cc-self-audit.sh does. Five degradation metrics and their thresholds The script measures five metrics and flags "red" when any of them crosses its threshold. # 閾値（env変数で上書き可） TH_INJECT_BYTES = " ${ SELF_AUDIT_TH_INJECT :- 40000 } " # rules+CLAUDE.md+MEMORY.md 合計バイト TH_AGENTS = " ${ SELF_AUDIT_TH_AGENTS :- 60 } " # ~/.claude/agents 配下 .md 総数（再帰） TH_STOPSPAM = " ${ SELF_AUDIT_TH_STOPSPAM :- 15 } " # 監査hook発火/週 TH_FRUSTRATION = " ${ SELF_AUDIT_TH_FRUST :- 8 } " # 不満ワード/週 TH_TOOLERR = " ${ SELF_AUDIT_TH_TOOLERR :- 400 } " # tool失敗/週 The first three are static metrics (state at this exact moment); the last two are dynamic metrics (trends since the previous run). That distinction maps directly onto how each one is measured, as described below. Overall design: a thr

In my previous post, Monitoring Claude Code hook watchdogs with launchd , I set up liveness monitoring for hooks — and immediately ran into the next question: a healthy hook means nothing if the product behind it is down. What I really wanted was a single page I could skim in five minutes every morning and know that everything is fine. That page is daily-brief.sh . launchd runs it three times a day (8:00, 10:30, and at login), and it compiles production HTTP probes, hook latency p95, launchd exit codes, 7-day API costs broken down by model, and per-project git status into one Markdown file appended to Obsidian. The problem: checking five places by hand every morning The more you automate, the higher the risk that something breaks silently. I used to open all of these manually every morning: The Vercel dashboard (production liveness) launchctl logs (scheduled job failures) Claude Code cost usage git status for each project The hook latency JSONL Just opening them took 3–5 minutes. Two incidents slipped through unnoticed (2026-06-11: GitHub Scout silently going blank, and a server configuration error in the autolike license API). Consolidating everything into one automatically delivered page makes missing things physically impossible. Overall design: 3 triggers → 1 Markdown file → append to Obsidian launchd ├─ StartCalendarInterval: 8:00 ├─ StartCalendarInterval: 10:30 └─ RunAtLoad: true（ログイン時） ↓ ~/.claude/scripts/daily-brief.sh ↓ ~/.claude/logs/daily-brief-YYYYMMDD.md ← 正本ログ ~/.claude/logs/daily-brief-latest.md ← 最新コピー ~/Desktop/Daily Brief/today-brief-YYYYMMDD.md ~/Documents/claude-obsidian/wiki/briefs/daily/today-brief-YYYYMMDD.md Even when the second run fires at 10:30, the marker <!-- daily-brief YYYYMMDD --> prevents duplicate appends (details below). The script opens like this: #!/usr/bin/env bash # launchd で毎日 8:00 / 10:30 / ログイン時 実行（再実行してもマーカーで二重追記しない）。 # 注意: Desktop / ~/Documents(vault) は TCC 保護領域 → plist は /bin/bash 直起動（FDA付与済み）。 # /bin/zsh 経由だと FDA 未付与で書き込

OhNine is a free menu bar app that tracks Claude session and weekly usage limits in real time It sends native alerts at 80%, 91%, and 100% so a session never ends without warning The hard problem was never reading a number, it was making the warning arrive before the cutoff instead of after Building a zero telemetry tool changed how I judge every product I ship after it The Problem: Hitting a Wall You Cannot See For months, my Claude sessions ended the same frustrating way. I would be deep in a conversation, mid thought, actually making progress, and then the reply would just stop. No countdown. No yellow light. No warning that said "you have three messages left, wrap up." One second I was working, the next I was staring at a message telling me to wait for a reset I never saw coming. The frustrating part was not the limit itself. Usage limits exist for a reason, and I understand why they are there. The frustrating part was the total lack of visibility into where I stood. Claude Code and claude.ai will occasionally mention you are close to a cap, sometimes at 97 percent, which is technically a warning and practically useless, because by then you are already mid-thought with no time left to land it cleanly. It got worse once I noticed the layers. There is not one limit to track, there are several stacked on top of each other: a session limit, a rolling weekly cap, and separate caps depending on which model you are running. Switching models mid-session, thinking you had found a workaround, only to hit a wall from a different direction, was its own specific kind of frustrating. None of these layers showed up anywhere. There was no dashboard, no menu bar icon, nothing you could glance at the way you glance at your laptop's battery percentage before deciding whether to plug in. So the wall kept arriving the same way: mid-flow, mid-sentence, with zero warning. Coding sessions got cut off between a question and its answer. Writing sessions lost momentum at the worst possibl

My previous piece, " Making a launchd Job Unload Itself ," built a job that runs exactly once and then unloads itself. This time it's the mirror image: a pattern designed around the assumption that the job will die mid-run — it fires several slots a day and delivers "retry until it succeeds, then quit immediately on success." Every morning I hand Claude Code the task of updating my Obsidian Vault, and it kept dying partway through — killed by macOS sleep, no network on wake, or a claude timeout. Instead of trying to prevent every failure perfectly, I decided "it can die overnight as long as it's done by the time I wake up" was the more realistic goal, and I redesigned around that. The problem: "started but didn't finish" piles up silently There are three ways a launchd job fails to run to completion. Lid-close sleep (on battery) — caffeinate -s only works on AC power. On battery, the job freezes the instant you close the lid, and gets reaped by timeout after wake. No network — right after wake, WiFi isn't connected yet. git push and claude's API calls time out. claude timeout — an ingest that chews through 28 hours of conversation logs doesn't fit in a single slot and times out (this happened three days in a row, 2026-06-11 to 13). All three can look like "the job started, exit code 0," so you notice late. Overall design: 4 slots + a done-marker The fix is simple: stuff multiple StartCalendarInterval entries into the plist, and at the top of the script check "if today's run already succeeded, exit 0 immediately." <!-- com.shun.vault-auto-ingest.plist (StartCalendarInterval excerpt) --> <key> StartCalendarInterval </key> <array> <dict> <key> Hour </key><integer> 4 </integer><key> Minute </key><integer> 55 </integer> </dict> <dict> <key> Hour </key><integer> 8 </integer><key> Minute </key><integer> 20 </integer> </dict> <dict> <key> Hour </key><integer> 10 </integer><key> Minute </key><integer> 45 </integer> </dict> <dict> <key> Hour </key><integer> 12 </integer><key>

When I built the MCP server for this project — it combines GitHub and DEV.to into a set of tools an agent can call — I had a decision to make before writing a single tool: talk to the low-level MCP protocol directly, or use FastMCP 's decorator API. I've seen a few "your first MCP server" writeups lately walk through the low-level path because it's more "honest" about what MCP actually is under the hood — JSON-RPC over stdio, a capabilities handshake, typed request/response schemas. That's true, and it's a reasonable thing to want to understand. But I want to write about the other side: what it actually costs you in practice once you have more than one or two tools, because I went through both and the difference showed up fast. what the low-level path actually asks you to write Strip away the decorator and MCP is a JSON-RPC server. For every tool you add, you're responsible for: Registering the tool's name, description, and a JSON Schema for its inputs in a list_tools handler Writing a call_tool dispatcher that matches on tool name and unpacks arguments by hand Serializing the return value into the TextContent / ImageContent wrapper types MCP expects Keeping the schema you wrote in step 1 in sync with the arguments you actually read in step 2, by hand, forever None of that is hard in isolation. The problem is it's boilerplate that scales linearly with tool count and has zero connection to the actual logic of the tool. My server has 8 tools. Hand-rolled, that's 8 schema blocks plus a dispatcher if/elif chain plus 8 response-wrapping calls, all of which exist purely to satisfy the protocol, not to do anything a GitHub or DEV.to API call needs. what it looks like with FastMCP Here's an actual tool from server.py , unedited: @mcp.tool () def get_repo_stats ( repo : str ) -> dict : """ Get stars, forks, watchers, open issues for enjoykumawat/<repo>. """ r = _gh ( f " /repos/ { GITHUB_USERNAME } / { repo } " ) return { " name " : r [ " name " ], " stars " : r [ " stargaze

The first sign something was wrong wasn't a crash. It was a pattern. blockly-platform was the first real thing I built with Claude Code end to end — a Blockly-based platform for university programming exercises, driven entirely through Claude Code's Telegram channel. No editor open, no repo checked out on my machine, just a chat thread. I'd describe what I wanted, Claude Code would build it on a box I never looked at directly, and I'd judge the result by clicking around the deployed app. On March 22nd, the home page came up empty. GET /api/exercises/published was returning 403. I said so in the chat; a few messages later, Claude Code said it was fixed — the endpoint hadn't been added to Spring Security's permitAll() list. I moved on, tried the category filter. Also empty, also 403, also missing from the same permitAll() list — same file, same class of fix, different line. Then the exercise detail page. Same story, third time, same day. Three days later, the like button stopped working — root cause, again: POST /api/exercises/*/like had never been whitelisted either. Four times, one file, one recurring gap. None of these were hard bugs. Each one, in isolation, is a one-line fix a competent engineer makes without thinking twice. What bothered me, once I noticed the pattern, was that I hadn't noticed it as it happened. I had no diff to scroll through, no file to glance at and think "wait, didn't we just fix this exact class of thing twice already?" I had a chat log and a live app to poke at. The fourth fix looked, from where I sat, exactly like the first: a message telling me it was resolved. That was the moment I started to suspect the problem wasn't the model. It was that nobody — not the model, not me — had anything to look at. Why chat-only vibe coding breaks down Here's what makes that pattern more interesting than "the AI made a mistake": every one of those four fixes was correct. Claude Code read the error, found the missing permitAll() entry, added it, and move

My CLAUDE.md has one line near the bottom that I wrote months ago and mostly forgot about until I started actually paying attention to what it does: ## Important Note after your work done codex will review what you done. Terse, no punctuation, clearly typed in a hurry. But it's a real instruction that fires on every session in this repo: I finish a change, and a second model reviews it before I consider the work done. I added it half as an experiment. A few months in, it's changed how I work more than almost anything else in the setup, and not in the way I expected. I thought it would catch bugs. Mostly it doesn't, not directly. What it actually does is force a triage decision on every single piece of feedback, and getting that triage wrong is where all the pain lives. The three buckets Early on I treated every review comment the same way: read it, do it. That lasted about a week before I was silently making changes I didn't agree with because a second AI suggested them, and separately burning a stupid amount of time re-litigating comments that were just wrong or out of scope. What actually works is sorting every comment into one of three buckets before touching code: Fix it, no discussion. The comment is unambiguous, low-risk, and doesn't touch anything architecturally significant. Just do it and move on. Ask first. The comment is ambiguous, or it touches something that would require a real judgment call, or the "fix" would be a bigger refactor than the comment implies. Stop and get a human decision before acting. Skip silently. The comment is a duplicate of something already handled, or genuinely doesn't apply. Don't reply just to say "not doing this," don't leave a comment thread as evidence of having read it. Silence is the correct response to a non-issue. The failure mode I kept falling into before I had these buckets explicitly was collapsing 2 into 1: treating "ambiguous" as "just pick an interpretation and go." That's the actual source of review fatigue, not

This is a follow-up to my earlier post, " Automating a config migration with a one-shot launchd job ." Some breaking changes come with a known expiration date, and you can prepare for them long before they land. This time the external event was the end-of-life of Fable 5 (2026-07-07), and I'll walk through how I designed a launchd job you set up today, that fires only on the target day, and that removes itself once it's done. The whole thing started with the thought, "manually fixing this on the shutdown day is going to be annoying." But I also didn't want to run a script every morning that needlessly rewrites JSON. What I landed on was a three-part set: a date gate, a jq rewrite with a backup, and self-unload. The problem: on the day I learn about a deprecation, I want to plant a job that "only runs on the target day" Right now, ~/.claude/settings.json looks like this: { "model" : "claude-fable-5[1m]" , ... } The moment I learned Fable 5 would end on 2026-07-07, creating a calendar reminder to manually rewrite this "model" felt too flimsy — I'll forget. On the other hand, making "a daemon that checks the date every time it boots" is overkill. What I wanted was a job I could set once and leave alone, that runs when the day arrives, and then disappears. launchd can fire at a specified time via StartCalendarInterval . But you can't express "just once at 9:00 on 7/7"; you need a combination of recurring and date-fixed slots. Specifying multiple slots and absorbing the redundancy with idempotency is the standard trick on macOS launchd. The implementation: the three-part set Here's the full ~/.claude/scripts/model-transition-0707.sh (comments omitted). #!/bin/bash set -uo pipefail SETTINGS = " $HOME /.claude/settings.json" LOG = " $HOME /.claude/logs/model-transition.log" PLIST = " $HOME /Library/LaunchAgents/com.shun.model-transition-0707.plist" log () { echo "[ $( date '+%F %T' ) ] $* " >> " $LOG " ; } # ① 日付ゲート if [ " $( date +%Y%m%d ) " -lt 20260707 ] ; then log "ski

Episode 1/4 — 3 incidents, one root: default GRANTs open more than you think — [CANONICAL URL EPISODE 1: fill in after push] Episode 2/4 — await mutation() lies when nobody opens the { error } envelope — [CANONICAL URL EPISODE 2: fill in after push] The morning Françoise sees zero rows, again It's a Tuesday in April 2026. I've just added the agent_readonly role to the authenticated membership — a one-liner, meant to share a GRANT for a reporting job. First SELECT on cours , Sentry receives infinite recursion detected in policy for relation "user_roles" , code 42P17 . From the office next door, Françoise is already on the phone with the Maisons-Laffitte branch: "So they can't see anything over there — is that normal?" Foreman tone, not really a question. I read the error on my screen. The difference from episode 1: this time Postgres is talking. What came out of Sentry was no longer a silent empty set — it was an explicit error. That difference saved me two days. When Postgres shouts, you listen. The trap is that what it says isn't where you're looking. I won't pretend this is obscure. A policy on user_roles that queries user_roles to decide who can read user_roles is a loop. You avoid it, you work around it with SECURITY DEFINER , you move on. The problem: my user_roles policy didn't reference user_roles . I had already cleaned it up three weeks earlier. The recursion was coming from somewhere else. The diagnostic that targets the wrong object First reflex: re-read the user_roles policy. It's clean, reads auth.email() , never calls itself. Second reflex: disable policies one by one to find the culprit. Wrong angle. -- supabase/migrations/20260420_admin_write_cours_v1.sql -- "Admin write cours" policy — original version that loops CREATE POLICY "Admin write cours" ON public . cours FOR ALL TO authenticated USING ( EXISTS ( SELECT 1 FROM public . user_roles WHERE email = auth . email () AND role IN ( 'admin' , 'super_admin' ) ) ); The recursion doesn't come from a fau

The fourth call of the week Catherine calls from the Maisons-Laffitte site on a Tuesday afternoon in early May. "It's broken, but it's a quick fix." That's her line — I know it, and she's usually right. She describes it in three sentences: the newsletter export for the enrolled-students segment comes back with ninety-two names, the planning view shows ninety-two active courses, but the counter page shows eighty-nine. Three enrolled students missing. She'd checked the database directly — they're all there. "Why three steps for that?" She's not asking for my benefit. She's asking for herself. Except this time, hanging up, I realize it's the fourth time this week I've hung up thinking the same thing. Four Supabase incidents, four fixes, four closed tickets. And not a single exception raised by the database. I reopen the three previous ones and lay all four side by side on screen. This isn't four bugs. It's one failure mode, declinated four times. The first three Episode 1 was about the default GRANT s Supabase places on functions and policies. A SQL function created without an explicit REVOKE inherits anon access that nobody wrote in the migration, and that nobody caught in review because the diff doesn't show it. The function works. It's just callable from outside. [CANONICAL URL EPISODE 1: to fill in after publication of #48 — "3 Supabase security incidents, one shared root cause: SECURITY DEFINER inherits EXECUTE TO PUBLIC"] Episode 2, an ON DELETE SET NULL cascade coupled with a CHECK NOT NULL on the target column. The parent DELETE attempts the SET NULL , the CHECK rejects it, and the transaction surfaces an error we read as a deletion failure — while it actually masks a consistency assumption we'd held for three months. The query fails loudly, which is more charitable than the other three cases, but the diagnosis heads in the wrong direction because nobody had declared that the two constraints lived in tension. [CANONICAL URL EPISODE 2: to fill in after publicati

The request was eight words Monday morning. I open the outgoing email queue: six hundred and forty-seven drafts waiting, six hundred and seventy-two sent. Nobody clicks Send . First-contact emails are prepared by a pipeline and they sleep, because the last step assumes a human. That human, I had stopped believing she would have the time. I state the decision: automate sending . The response comes in seconds. Three levels of automation. Four channels. Three risk thresholds. All correct, all fit for a half-day architecture workshop. I had not asked for a workshop. Pauline walks behind me, glances at the screen, says nothing. Three timed reframes First reframe , brief: too strange, let's simplify . The agent drops two axes, keeps four residual layers, progressive warm-up over three weeks, deterministic anti-replay hash, configuration table in the database, manual Phase 1 followed by an automated Phase 2 to validate after two weeks of measurement. The target stays the same, that an email leaves without a human click. The path has grown accordingly. Second reframe , drier: simple, three safeguards, a kill-switch, we do this in one day . The agent re-architects, accepts the one-day target, keeps the three safeguards. But slips in three prostheses it calls industry standard : real-time dashboard, exponential retry, structured audit log in a new table. Each justifiable in isolation. None of them requested. Third reframe , shorter still: I don't understand why you're adding this . An opening line almost embarrassed, which I had never read from it before: "you're right, I'm over-engineering without necessity." And the version that should have arrived on the first round. A function that takes the draft record, checks three conditions, calls the send engine, returns. // lib/email-outbox.ts — generateFirstContactDraft (commit 3756e63) if ( ! EMAIL_REGEX . test ( input . email )) { return { success : false , error : ' email_invalide ' } } if ( BLACKLIST_EMAILS . has ( input . ema