Cooking on Real Beat

Before the Meter Started Running, I Had the AI Build an 'Environment' Instead of a Deliverable

Thu, 02 Jul 2026 21:04:06 +0900

Honestly, I can’t keep up with how fast AI models are turning over lately. A new one shows up every few days, and whatever was “the best” a moment ago is already last-gen. The incident I mentioned in an earlier post — a model that got cut off just three days after launch — is part of the same story.

In the middle of all that, I noticed something about my own plan: Claude Fable 5 only counts toward my free weekly usage cap until July 7, 2026. After that date it doesn’t stop working — it just switches to pay-per-use. So the question became: what do I spend the free allowance on while it lasts?

The obvious answer is to throw it at the hardest task on my plate right now — get it to write a difficult article, or push through some gnarly refactor. But do that, and all you get out the other end is one article, one piece of code — a “deliverable.” The moment it’s written, it’s just text sitting there. Even after the free tier runs out, handing the same job to a different model would probably get you something of similar quality anyway.

So what would actually pay off after the billing kicks in? I didn’t have a clean answer, so I decided to just let it loose on my external brain and see what happened.

Handing over the whole external brain for inspection

I already run my Obsidian vault as an external brain, carrying memory across sessions the way I described in an earlier post. A bug I fix today is done today, but the setup of the external brain itself keeps getting used, in the same form, for as long as I keep using it. So I asked Fable 5 to audit the whole thing.

The instruction was about as vague as it gets: “Is there anything about my external brain that could be organized better?” What came back was more specific than I expected.

The freshness check on persona.md (a summary note of ongoing work) wasn’t actually running. The config file said it would “auto-regenerate on startup,” but nothing was actually wired up to do that, and it had sat untouched for nine days. Automation that only exists as a line in a prompt fails silently.
A folder I’d deprecated still had write rules pointing at it. I’d consolidated everything into a different location, but forgot to remove the old “write here” instructions — a hole where information could vanish the instant it was written.
A folder for auto-collected news had grown without bound. Two digests landing every day had turned into search noise.
Records of “why I decided this” were thin. Decisions were buried inside daily work logs, making them hard to trace back later.

Each point on its own was minor. But every one of them, if fixed today, would still be there tomorrow no matter which AI I happened to be using. That’s when I found my answer: don’t have it produce a deliverable (a flow) — have it build an environment (a stock).

Steering the fixes toward “machinery” and “public code”

While making the fixes, I made a point of not letting anything stay scoped to just this one conversation with Fable 5.

No amount of careful prompt-wording was going to fix the freshness-check problem, since the same hole would just reopen later. So I added a small shell script that runs at session start: if a note’s timestamp is more than seven days old, it throws a warning automatically. That closes off the “written down but not actually running” failure mode, at least mechanically.

For the bloating news folder, instead of a quick manual cleanup, I implemented a proper “keep N days” setting in the collection script itself, and submitted it as a pull request to obsidian-vault-search, a repo I maintain publicly. While I was at it, I also added an “exclude this folder from search” option to the search tool. Neither of these is a private hack just for me — they’re now features that live in the repo. Once the free tier ends and Fable 5 starts costing money, whatever’s merged into main stays merged.

Recording the reasons I decided not to do something

Along the same lines, I looked into whether I could offload some lightweight tasks to a local LLM (Gemma) instead. My Mac already has a 4B-class model installed. But it only has 8GB of memory, which puts a hard ceiling on what it can realistically run.

Even accounting for that, I ended up deciding against it. Two reasons. First, the place where I’m actually spending the most (day-to-day conversation and scheduled tasks) isn’t somewhere a local model can slot into anyway. Second, output from a weaker model tends to cost more in review time than it saves — which would contradict a conclusion I’d already reached: that review time, not generation time, is the real bottleneck.

What matters here isn’t the “no” itself — it’s that I wrote down why. Next time the same idea crosses my mind (mine or another AI’s), I won’t have to redo the whole evaluation from scratch. It’s not just the features you adopt that become part of the environment — the reasons you rejected something do too.

Then I asked it to pitch me an article

Once everything was fixed, I asked, more or less as an afterthought, “Could this whole thing be a blog post?” What came back was essentially the outline of the article you’re reading right now.

Fable 5 audited the external brain. Fable 5 fixed it. Fable 5 turned the record of those fixes into a story pitch. And right now, that same Fable 5 is the one helping me write this article out of that material. It’s nested: a model that’s about to become billable in a few days made changes that will outlive that deadline, and then wrote an article using the record of those changes as its source material. Though of course, this article is itself, in the end, just another “deliverable.” What survives past the end of the free tier isn’t the article — it’s the audit and the fixes behind it.

But that doesn’t feel like much of a contradiction. Whichever model I use next, the hook still runs, the code in the public repo still works. This whole exchange is sitting in the vault too. Some time from now, when a different AI opens this vault, what it references won’t be this article — it’ll be the Decisions note behind it. Just like “why I didn’t use Gemma” got written down, this whole exercise gets recorded too, as “why I had it build an environment instead.”

Closing

When I wrote about the AI that vanished after three days, I was looking at the risk of a dependency disappearing, from the outside. This time it was the mirror image: knowing in advance that an AI was about to stop being free, what should I actually ask it to do?

The strongest models tend to get pointed at “outputs” — articles, code. But outputs can be regenerated by the next model just fine. What doesn’t get rewritten is a single hook script, a pull request merged into a repo, a Decisions note that even records why you didn’t do something. If you can see the free tier ending, spend it on things that outlast the deadline, not things you could only make within it. That way, whichever AI shows up next doesn’t have to trip over the same hole all over again.

I Googled 'best language for AI' and realized the map was pointing backwards

Thu, 02 Jul 2026 17:51:41 +0900

I searched “best language for AI.” What came up was Python, R, Julia — one of the rewritten articles even still had a leftover “as of May 2019” buried in the text that nobody bothered to delete.

I read through it and thought: wait, this isn’t the answer I was looking for.

The arrow is pointing the wrong way

What articles like this actually answer is “if you’re building AI, which language should you use?” Python with its deep ML library ecosystem, R for statistics. The arrow points from language to AI. Call this axis 1.

But what I actually want to know right now is the reverse: “what does AI write, when I let it choose?” That’s axis 2 — the arrow pointing the other way.

Having Claude Code write code for me every day, I already know the answer in my gut: TypeScript. Ask it to build something new without specifying a language, and it comes back as TS or JS almost every time. The map you get from googling “best language for AI” simply doesn’t apply to this flipped-arrow world anymore.

So why TS? As it happens, the news sitting in my feed lined up almost too neatly to explain it.

The JS toolchain is quietly being rewritten in Rust

Over the past few weeks, “Rust” kept showing up in my news roundup. Vite 8.0 shipped with Rolldown, a Rust-based bundler, as its default. VoidZero, the company behind it, got acquired by Cloudflare. webpack, Babel, ESLint, Prettier — the JS/TS-based, single-threaded, GC-reliant staples of the toolchain are being replaced with Rust implementations one after another.

The reason is simple: speed. Rust tools run natively with no GC and full multithreading, and they’re 10 to 30 times faster than their predecessors. On top of that, shared Rust-based parser/AST infrastructure like Oxc has matured, which is cutting out the waste of bundlers, transpilers, linters, and formatters each re-parsing the same code independently. Rolldown (Rollup-compatible), Rspack (webpack-compatible), Biome (ESLint+Prettier-compatible) — these are all built as drop-in replacements that don’t break your existing config or setup, which is part of why adoption has been so smooth.

That said, this shift predates the AI boom — it traces back to esbuild’s debut around 2020. The motivation was speed and untangling toolchain fragmentation, not AI directly.

Still, the two fit together well. AI agents run “edit → build → test → lint” dozens of times within a single task. The faster the tools, the cheaper and faster that loop runs. A build that takes tens of seconds translates directly into agent wait time and token spend. And as AI-generated code volume grows, so does the total amount of building and analysis that needs to happen. I suspect that’s exactly why Publickey’s 2026 predictions piece mentioned “AI-agent-first development” and “expanding Rust adoption” in the same breath — the fit is too good to be coincidence.

TS is rock-solid as a language, but its implementation is leaving its mother tongue behind

Inside this Rust wave, TypeScript’s position has become genuinely interesting. As a language, TS is if anything getting stronger — Node, Deno, and Bun are all converging toward running .ts files directly, and there’s no sign of that trend wavering.

Meanwhile, the tools that process TS are going native at a rapid clip. Type transformation is now handled by SWC, esbuild, and Oxc (Rust/Go), and the crown jewel is the type checker itself: tsc. On June 25, 2026, Microsoft shipped an RC of TypeScript 7.0 (Project Corsa). The port target: Go. Compilation is roughly 10x faster, editor startup roughly 8x faster, and memory usage is nearly halved. Google, Notion, Slack, and Vercel have already adopted it externally.

Here’s the part that snags. If you’re chasing raw speed, Rust should be the obvious choice. So why Go?

The answer isn’t “because Go is better” — it’s “because the existing tsc could be ported as-is.” Under the hood, tsc is a massive graph of mutable objects with circular references — ASTs, cross-referencing types, all built on the assumption that a garbage collector is there to clean up after aggressive in-place mutation. Go lets you carry that structure over almost 1:1. Rust’s ownership and borrowing model actively resists circular references and mutable graphs like this, which would have meant a ground-up redesign. Anders Hejlsberg himself confirmed this wasn’t a judgment about language quality but pure pragmatism: he chose Go because it was the fastest path to a 10x-faster codebase.

So tsc’s implementation ended up in Go not because Go was objectively “best,” but because of path dependency — the ability to carry existing assets forward as-is. Being logically correct loses to an accumulated path that already works. And this, it turns out, is a preview of the same shape I’ll return to later: TS winning as a language isn’t about technical optimality either — it’s about owning the web and having a massive training corpus, which is also just path dependency.

“Writing in TS” hasn’t changed, but “the tooling that processes TS” is drifting away from its own mother tongue. TS 7.0 is a live demonstration of that split — the official TypeScript compiler is no longer written in TypeScript. And yet, the list of companies adopting it also confirms, in the same breath, just how solid TS remains as a language.

Why AI reaches for TS isn’t about type “quality”

Back to the main question: why does AI tend to write TS?

The tempting explanation is “because it has types, so AI can verify its own output more easily.” But that needs a correction — better verifiability from types is a property of typed languages in general, not something unique to TS. And TS’s type system is deliberately unsound; if you’re ranking strictly by type rigor, Rust or Haskell wins easily. On type quality alone, TS doesn’t come out on top.

So what’s actually driving it? First, you can’t ignore TS’s lock on the web/npm ecosystem. JavaScript is essentially the only language that runs in a browser — that’s a structural moat with no real substitute. Then there’s the sheer volume of training data. According to GitHub’s Octoverse 2025, as of August 2025 TypeScript overtook both Python and JavaScript to take the top spot in monthly contributors, at 2.636 million — a 66% year-over-year jump, one of the biggest ranking shifts in a decade.

When I tried to double-check one of my own assumptions here, things got twisted. I’d been carrying around an explanation like “types make it well-suited to the generate-loosely-then-tighten-later loop AI agents run.” The actual measurements say the opposite. A benchmark published by mame has Claude Code solve prototyping tasks across 13 languages and compares time and cost. The fastest, cheapest, and most stable were Ruby, Python, and JavaScript — not TypeScript. TS ranked 11th out of 15, taking 1.6x longer than JavaScript and costing 60% more. The overhead of the type system was actually slowing the agent’s iteration loop down, not speeding it up.

The upside of types — catching AI’s mistakes early — does seem to be real. One study found that 94% of compile errors LLMs produce are type-check failures. Static typing functions as a net that stops AI’s sloppiness before it reaches production. But that’s a separate axis from whether an agent can actually write faster and cheaper in practice — and on that axis, the measured cost of types outweighed the benefit.

So “AI writes TS best, technically speaking” isn’t a sufficient explanation for TS’s rise. A GitHub developer advocate calls this the “convenience loop”: developers flock to whatever technology makes AI feel easy to use, which grows the training data for that technology, which makes AI even better at it. TS just happened to catch this loop earliest, and once you’re riding it, the loop keeps spinning regardless of technical merit.

I’d been thinking “TS is what AI writes best, so left unchecked, things gravitate there.” The more accurate version is: “it gravitates there regardless of whether AI writes it best — because the loop it’s riding is simply bigger than the alternatives.” And this is the third face of a shape this piece keeps circling back to. TS winning as a language, tsc’s implementation ending up in Go, AI gravitating toward TS — all three share the same root. Being logically correct loses to an accumulated path that already works.

Path dependency can also be a wall

Everything so far has been examples of path dependency on the “ride it and it accelerates” side — TS’s convenience loop, tsc’s Go port. But path dependency has an opposite face too: the side where an accumulated path leaves you stuck, unable to move.

The clearest example is COBOL in banking. Systems written decades ago are still running at the core of settlement infrastructure today. Technically, it’s about as frozen as software gets, and there must have been people wanting to rewrite it for years. But it doesn’t move.

My first instinct was that COBOL’s immobility is a “people” problem. The engineers who wrote it have retired, or worse. Documentation is gone. Fewer young engineers can even read COBOL anymore. If that’s the whole story, this should be exactly where AI shines — reading mountains of undocumented legacy code and explaining it is precisely the kind of work today’s LLMs are eager to do. And indeed, AWS has a product that scans legacy codebases to surface technical debt — legacy migration support is one of the current front lines of applied AI.

But that alone doesn’t feel like the full picture. Decades of patches have piled up in COBOL settlement systems, and the answer to “why does this one line exist” is sometimes something like “it works around a specific edge case that happened some years back” (a generic example, not a real one). AI can read that logic and explain it — the wall of understanding is genuinely being worn down by AI.

But a different wall remains: proving that the rewritten system behaves identically to the original, down to the last detail. You have to convince regulators and auditors that the new and old systems produce matching results across every transaction pattern that could occur in production. That’s not “read and understand” work — it’s “enumerate everything that could possibly happen and verify it,” a completely different axis from how fast you can read code. AWS’s own writeup on lessons from real-world COBOL modernization points to the same thing: the main causes of failure weren’t a lack of technical skill in the port itself, but the inability to prove functional equivalence against real production data, and organizations underestimating the effort involved.

In other words, the COBOL wall isn’t one wall — it’s two walls stacked on top of each other: a wall of understanding and a wall of proof. AI is chipping away at the former. The latter still only moves at the speed of human trust.

TS’s path dependency was a moat that accelerates the moment you get on it. COBOL’s path dependency is a wall made of a part that’s crumbling and a part that isn’t. Same underlying shape — path beats logic — but which parts AI can change and which it can’t differ completely.

So for now, I’m betting on TS

Back to where this started: “best language for AI.” Articles like that are mapping a world where you use a language to build AI. What I actually wanted was a map of what AI writes when it’s driving — a different axis entirely. Picking a language off the old map doesn’t answer the question I actually have.

Right now, the answer to axis 2 is TS, and what’s propping it up isn’t technical optimality — it’s the sheer size of its convenience loop. Loops that big don’t collapse easily. Betting on TS for now seems like the rational call, regardless of whether it’s the technically optimal choice. Though it’s worth remembering: if all you want is the fastest possible working prototype right now, plain JavaScript or Python will get an agent there faster and cheaper than TS will. If you’re trying to decide what to learn and you’re stuck on language choice, you’re better off looking at what AI agents can actually write well and fast today than trusting whatever stale “best language for AI” article turns up in search.

My phone's external brain was a dead end — until I found the loophole called Remote Control

Wed, 01 Jul 2026 23:09:17 +0900

For a while now, I’ve been syncing my Obsidian vault between my Mac and Android phone with Syncthing. It’s an OSS tool that copies files directly between devices on the same Wi-Fi network, no cloud in between. Thanks to that, the external brain’s vault has already been sitting on my phone for a while.

Right after publishing my previous post, a question popped into my head. If everything’s synced that thoroughly, couldn’t I use the external brain from the Claude app on my phone too?

The data is already on the phone. So why had I been assuming all along that it just wasn’t possible?

Synced, but no legs to walk over there

When I looked into it again, the problem wasn’t where the data lived. It was how to reach it.

The Claude.ai phone app has a feature called Projects for custom instructions. But its contents are a snapshot you upload by hand each time — it’s not built to point at a folder and read it automatically, the way CLAUDE.md works. There’s a memory feature too, but you can’t see or edit what it’s actually remembered. That’s exactly the “weakness of official memory” I wrote about in my first post on the external brain.

The vault genuinely exists on the phone. But the Claude app on the phone has no hands or feet to reach it with. The sync was done, but the tool wasn’t built for it. So I concluded, once, that it was hopeless.

The loophole called Remote Control

But digging a bit further, I found that Claude Code has a feature called Remote Control. It lets you operate a session running on your PC remotely, from the official phone app.

Once I saw how it worked, it clicked. The actual execution still happens on the PC. The phone is just a window for controlling it. Which means: if the Claude Code session on the PC can already read and write the vault via MCP, you can issue commands from the phone while keeping all of that access intact. It’s not “read the external brain from the phone app alone” — it’s “drive the PC’s fully-equipped session by remote control, from the phone.”

I set it up and tried it, and it worked. I hesitated for a moment on the phone side, picking which PC session to connect to, but once connected, everything worked as usual. Searching with vault-search, loading persona/MOC files, the write rules — all of it, in the same state as on the PC, usable from the phone. There was a path after all, in the place I’d assumed was a dead end.

If the PC is asleep, none of it matters

After the initial excitement of getting it connected, I realized there was another precondition. Since the actual execution happens on the PC, the PC has to be awake for any of this to work. A locked screen or a dark display is fine, but if you explicitly close the lid and put it to sleep, the connection drops.

What I found interesting is that the same “is the Mac asleep” question doesn’t apply to the news digest that lands on its own every morning. That one runs from the cloud side via Claude Code’s scheduling feature, so it fires whether the Mac is asleep or awake. Remote Control is the opposite — it depends on the PC actually being up and running. Both look like “AI working in the background” on the surface, but where it executes changes everything about the preconditions.

So to use this from my phone, I need to make sure the Mac won’t sleep before I head out. Leaving caffeinate running in a terminal works, but it’s annoying to have it hog a tab. I ended up either backgrounding it with caffeinate -d &, or more simply, just clicking on Amphetamine, a menu bar app that does the same thing in one click.

Along the way, I found another memory layer

Somewhere in the middle of all this, I found one more thing. A way to full-text search past sessions themselves.

Until now, I’d assumed the external brain was entirely the vault I’d hand-written into — Knowledge, Decisions, daily logs. But separately from that, the sessions’ raw conversation logs were also being kept, and they were searchable. I tried searching for “syncthing” out of curiosity, and two sessions came up from the day I set up Syncthing between Mac and Android.

One was the session where I actually set it up; the other was from the planning stage, and it still had the whole comparison conversation preserved — “Obsidian Sync is the easiest at $4/month, Syncthing is free but takes more setup.” The reason I’d chosen Syncthing wasn’t written down in any note in the vault. Not because I forgot to write it — I set up Syncthing on June 19th. The external brain’s write rule (the mechanism of recording decisions into Decisions) didn’t exist until the June 21st post. In other words, when I had that Syncthing conversation, the whole idea of “keep a record of decisions” didn’t exist yet.

I’d thought the external brain was just the hand-curated vault. It turns out there’s another layer underneath, uncurated, where everything is kept as-is. Even decisions made before the vault’s rules existed can be dug back out by searching the conversations themselves. One extra layer of safety net, that I didn’t know I had.

Memory turned out to have three layers

Putting it together, here’s the structure the external brain has now.

At the top is the hand-curated vault. Second is the raw session log that’s kept in full, uncurated. Third is Remote Control, which makes both of those reachable from the phone too. The top two are memory itself; the third is the access path to it.

My previous post was about keeping the option open to move away from my current AI provider. This one is the opposite — it’s about deepening my dependence on the AI I’m already using. By making it usable from my phone at the same depth as on the PC, my dependence on Claude Code got even stronger.

Still, I think both posts share the same root. They’re both about “not letting the choices you already have stay narrow.” Last time it was about where to go; this time it’s about how to get there. Reducing dependence, and expanding what you can do within that dependence, turned out to be two different axes — something I only noticed by writing this.

I’m glad I didn’t just stop at “probably not possible” and looked a little further.

What If My AI Vendor Disappeared in Three Days? Why My Second Brain Ended Up Not Locked Into One AI

Wed, 01 Jul 2026 18:06:43 +0900

Last week, a new model got cut off just three days after its public release, and the news framed it as “the blind spot of depending on foreign AI.” I won’t get into the details here, but the headline alone stopped me in my tracks. Right now, I’ve put my entire second brain and workflow on Claude Code. If Claude became unusable tomorrow, would my “brain” go down with it?

That thought sent me back to audit how my second brain is actually built. The short answer: it wouldn’t go down with it. I didn’t design it that way on purpose. Decisions I’d made for entirely different reasons turned out, later, to double as insurance.

What I’ve actually put on Claude Code

Counting it up again, it’s a fair amount. I turned an Obsidian vault into external memory, and I have it read and write there at the start of every session. I added semantic search on top. I also built a persona/MOC pair that distills who I am and maps out the terrain. Records of my mistakes, records of my judgment calls — all of it has piled up through conversations with Claude Code.

Hearing all that, it sounds like textbook lock-in. Memory I’ve spent months growing, all sealed inside one AI tool, freezing solid the instant that tool disappears. A pretty common shape of dependency.

But look inside, and it isn’t sealed at all

Except when you actually look at what’s stored, the picture changes.

The vault itself is just Markdown files. Not on Anthropic’s servers, not in some Claude-specific format — plain text files sitting on my local disk. That was a deliberate choice from day one: when I first built the vault, I listed “opaque contents” and “can’t hand it off to another AI” as weaknesses of the official memory feature, and built the opposite on purpose. At the time I thought of it purely as a transparency choice. Looking at it now, in light of this incident, that same choice turns out to have been portability all along.

Semantic search is the same story. vault-search is a hybrid setup that blends semantic and keyword search, but neither half calls Claude’s API. Embeddings are generated locally via Ollama, and the search itself runs entirely on local Python and SQLite. If Claude Code disappeared tomorrow, vault-search "how did I handle that thing" would still work exactly as before. In fact, I built this CLI specifically so it could be invoked from any tool, not just Claude.

persona.md and MOC.md are the same. The generation step (/persona-refresh) is a Claude Code command, sure, but what it produces is just a single Markdown file. If the mechanism that built it vanished, the last-generated file would still be sitting right there on disk. Whatever AI reads it next can read it just fine.

The only Claude-specific part is “how to read it”

So what actually is Claude-specific? The rules for how to read and write all this — in other words, the contents of CLAUDE.md. At the start of a session: skim mistakes.md and persona.md to get the big picture, dig into vault details with hybrid search, never take an “unverified” label at face value — right now, these steps only exist written down in Claude Code’s config file.

But that’s still just text. If I ever needed to migrate, I could copy these read/write procedures into another AI tool’s config format and reproduce the broad strokes. I wouldn’t need to rebuild the knowledge itself from scratch. The most time-consuming part — growing the vault to a thousand-plus files — is already done. What’s left is the lightweight part: teaching a new reader how to read it.

The cost of switching AI vendors turns out to live in copying over a config, not in rebuilding knowledge. That was the single biggest thing this audit turned up.

“Don’t leave it to the AI” did double duty

Tracing back why things ended up this way, it all leads to one policy. In the first post I decided not to let the AI set the standard for what counts as memory, and in the persona/MOC post I put it into words again as not letting the AI decide what’s worth remembering. That’s the throughline.

Originally, this was purely about not letting memory become a black box. I wanted to be able to see for myself what was stored, and to set the standards myself. There was no scheme to hedge against any particular AI going away.

But push “don’t leave it to the AI” far enough, and you inevitably end up avoiding anything that exists only inside one company’s walls. Keeping the contents visible to yourself means, almost by necessity, keeping them in a form readable elsewhere too. I was chasing transparency, and portability came along for free.

There’s one more piece: the “confidence labels” I adopted while evaluating a tool called graphify take on a second meaning here too. Every claim written into the vault gets tagged verified / inferred / needs-check. Originally that was purely so my future self wouldn’t mistake an old guess for an established fact. But even if the reader changes to a different AI, the label still does its job — a new reader won’t blindly trust a guess left behind by the previous reader (Claude). It turned out to be a hedge against the writer changing too, not just the reader.

This isn’t about cutting ties

To be clear, this isn’t “I’m preparing to quit Claude.” I still use Claude Code every day, and I have no plans to switch. What I did here wasn’t an actual migration — just an audit of the existing design, to check whether I’d painted myself into a corner.

What matters, I think, isn’t cutting off dependency — it’s staying dependent while keeping the option to leave open. Rebuilding everything from scratch yourself is unrealistic, and there’s nothing wrong with using what’s convenient. But in exchange for that convenience, you should still get to choose where the things you hand over actually live. In my post about tidying up passwords, I wrote about not trusting whatever’s shown to you in the moment, and instead routing judgment through a pre-shared secret or a separate channel. This is the same idea, just aimed differently — that post was about protecting information on the human side; this one is about protecting against the AI vendor itself disappearing. Don’t bet everything on one central point — always keep a route you can move through.

The story of an AI cut off after three days was supposed to have nothing to do with me. But once I asked “what if it were my AI that disappeared” and actually went digging, I found that old design decisions had quietly been insurance all along. Since I never set out to build that defense, finding it there felt like a small, unearned win.

I Went Through My Amazon Order History and Only 4 Purchases Actually Held Up

Sat, 27 Jun 2026 18:00:24 +0900

We’re already halfway through 2026, so I went back through everything I bought on Amazon this year. 75 orders total. Lined up like that, most of it turned out to be recurring supplement subscriptions, cat food, and ingredients for cooking at home — 10kg of soybeans, koji, kombu, dried shiitake, natto spores. Even I have to admit it’s a pretty plain lineup.

Once I set aside all the consumables and kept only the things I can genuinely say I’m glad I bought, it came down to four. The prices and categories are all over the place, but each one actually changed something about how I live. Here they are, in order.

MacBook Neo A18 Pro: if you want one, just buy it now

I picked up the 13-inch model in June for just under 100,000 yen. No contest — this is my best purchase of the year.

It’s small and light, full stop. And despite that, it runs on the A18 Pro, so nothing about my day-to-day work ever feels sluggish. Getting this size, this weight, and this much performance for under 100,000 yen honestly doesn’t add up when you think about it. On top of that, the design is just good-looking. Feeling good about the thing you’re carrying around matters more than people admit, especially for a tool you use every single day.

On the price front, memory costs and everything else are pushing PC prices up gradually right now. So if you’ve been telling yourself “I’ll get one eventually,” there’s not much reason to wait. Every day you hold out for a lower price is really a bet on it getting more expensive instead. If you want it, buy it now — that’s the honest takeaway here.

Like-it frozen rice containers: unglamorous, but I touch it every day

I bought a 6-pack of these in January for a bit over 3,000 yen. There’s nothing flashy about them, but in terms of satisfaction, this might actually rank right behind the MacBook.

I used to assume all frozen-rice containers were basically the same. I was wrong. Each one holds exactly one serving (160-200g), and once it’s thawed you can just pop it straight into a rice bowl — the shape is built to match. And the rice itself doesn’t turn soggy. The containers are designed to let steam escape, so even after microwaving, the grains stay separate and intact instead of turning to mush.

That “kind of watery, kind of sticky” annoyance you get with frozen rice disappeared the moment I switched containers. For someone who cooks a big batch of rice and freezes it instead of cooking daily, that difference is huge.

Nadesori hair-removal roller: hair removal by just petting your skin

Bought this in May for 2,450 yen. This one was a total surprise pick.

The idea is that you roll it over your skin and it removes unwanted hair — no cutting, no pulling. I was skeptical, but once I tried it, what stood out was how little damage it does to your skin. None of the nicking you get from a razor, none of the pain of an epilator.

It won’t do a deep shave — this isn’t a tool for clearing thick, fully grown-in hair, it’s for maintaining skin that’s already been mostly cleared. Within that use case, it’s genuinely impressive. The hair it removes doesn’t scatter much either, so cleanup is easy, which matters more than it sounds. A tool that lowers the mental barrier to actually doing your grooming routine ends up being the one you keep using long-term.

Fascia release gun: forgivable, for the price

I can’t give this one an unqualified rave. It’s a cheap one I picked up in January.

It does work. Point it at a tight calf or shoulder and it loosens up. Given the price, that alone is a pass.

That said, cranking it up to max power means holding the button down the whole time, rather than just setting a level and letting it stay there — a bit of an annoyance. Every time I use it I think “ugh, this again.” Still, if this price gets you massage-gun-level results, that complaint is easy to live with. It’s the kind of tool you use with a shrug of “well, you get what you pay for.”

Looking back

Lined up together, the only expensive purchase here was the once-a-year MacBook — everything else was a few thousand yen. And yet satisfaction didn’t track with price at all. Cheap, everyday items like the rice containers and the hair-removal roller ended up punching well above their price tag.

Picking out the things you’re actually glad you bought turns out to be a backwards way of noticing where you’ve been quietly annoyed every day. I’m guessing the second half of the year will bring more of the same — plain ingredients, supplements, and a handful of small gadgets mixed in.

Adding a Layer That Grasps the Whole Picture to My External Brain, Making Recall Two-Tiered

Fri, 26 Jun 2026 17:06:05 +0900

This continues the story of switching my external brain’s search to semantic search. Last time, I noticed that keyword search on my vault was missing things, so I added local embeddings via Ollama for semantic search. Now even a vague query like “how did I set up gitleaks again” pulls up the right daily log.

That made pulling specifics much better. But as I kept using it, I noticed a different gap. There was no entry point for grasping the whole picture broadly.

You Can Pull Points, But Not See the Whole Plane

What semantic search gives you is the ability to pinpoint a single past moment. You have a question, and it digs up the note closest to it. That’s a “point” motion.

But when a human actually recalls something, they don’t jump straight to a point. First they grasp the whole situation — “I’m in this kind of situation right now, working on this kind of thing, it’s roughly about this” — and only then dig into specifics.

Claude Code’s external brain didn’t have this “grasp broadly” side. When I checked the aggregated profile it’s supposed to read on startup, it turned out to be essentially empty. Who I am, what I’m working on, what’s been happening lately — none of that was pulled together into one place. The facts were scattered across personal-info notes, mistakes, individual projects, and daily logs, but nothing handed over the big picture the moment it started up.

So every time, at the start of a session, I’d hit semantic search a few times and reconstruct the situation from fragments. Pulling several points and guessing at the plane from them. It would be much simpler to just hand over the plane itself from the start.

Recall needs two layers: one that grasps broadly, and one that pulls specifics. I’ll call the former macro and the latter micro. What I built with semantic search was only micro. This time, I’m adding macro.

Stealing the Philosophy a Second Time

Last time, I wrote about evaluating TencentDB-Agent-Memory, a tool for giving agents long-term memory, and ended up only borrowing the one idea of semantic search and building it myself. That tool has more to it: it distills conversations through four layers — facts, scenarios, and persona. The topmost layer is a picture of “this is who this user is.”

What I wanted for macro was exactly that. Something that pulls out only the essentials from scattered facts and condenses them into a single picture of who I am and where I currently stand.

But I wasn’t going to bring the whole thing over. Same as last time. That tool auto-extracts memory from conversations. But in my very first post about the external brain, I decided that “what to remember shouldn’t be left to the AI.” Auto-extraction runs head-on into that principle.

So I stole only the philosophy. I took the idea of “distilling a person’s profile into a single note.” I threw out the implementation of “having the AI do it automatically.” What I do is just pull out the essentials, and only build it from handwritten primary-source notes.

Persona: A Single Note Distilled From What I Wrote by Hand

What I built is a single note called persona.md. It sits at the root of the vault, read first on startup alongside mistakes and TODOs.

The contents: who I am, my working style and preferences to respect, what’s currently in motion, recent developments, and entry points for digging into the past. I didn’t try to cram everything into a summary — for details, I link out to personal-info notes and individual project notes. Macro gives you the grasp, and from there you can drop down into micro if needed.

I built a command called /persona-refresh to generate it. All it does is read handwritten primary-source notes and summarize them. No auto-extraction from conversation logs. Source links are mandatory, and filling in gaps with guesswork is forbidden. The only facts allowed in are ones I wrote down somewhere myself, by hand. The AI distills, but it doesn’t invent material.

One problem: with this kind of manual regeneration, it’s never clear when you’re supposed to run it. Forget to run it, and it just rots out of date. So on startup, it checks the date — if persona.md doesn’t exist, or if it’s been more than seven days since the last update, it auto-regenerates before being read. I can still trigger it manually anytime, and if I leave it alone, it refreshes itself within a week regardless. I keep manual control without giving it up, while decay gets stopped automatically.

MOC: The “Plane” Search Can’t Pull Up

Alongside persona, I also put in a MOC.md. Map of Content — a map of my notes.

This is a longstanding idea in the Obsidian community: build a single handwritten index by domain that ties all your notes together. Divided into categories like self, environment and tools, blog, projects, and logs, with links out to each hub note.

Why do you need an index when you already have search? Because search is a tool for pulling “points.” You throw a query, and the closest matches come back. But “what kinds of clusters even exist in this vault in the first place” isn’t something search can grasp. I wanted to survey the terrain itself before even framing a question. Only a handwritten map can do that. Where search pulls a point, MOC surveys the plane.

Now the external brain’s recall is two-tiered. On startup, persona and MOC first give a broad grasp of “here’s who you are, what you’re working on, and here’s the map.” From there, individual questions get answered by vault-search’s semantic search pulling specific points. Grasp broadly, then drop to a point. This is the motion I originally wanted.

While I Was At It, I Evaluated One More

While building macro, I also looked at another memory-related OSS project. graphify, a tool that turns code and documentation into a knowledge graph.

I didn’t need the whole thing here either. It comes with a graph database and HTML visualization — overkill for a personal vault. But there was one good idea in its design. It labels extracted relationships with a confidence level: facts explicitly stated, relationships connected by inference, and things suspicious enough that a human should look at them. It distinguishes these three tiers and surfaces the suspicious ones in a report for a human to judge.

My external brain had the same hole. Up to now, whenever Claude Code wrote knowledge into the vault, a verified fact and an in-the-moment guess sat there wearing the same face. My future self, in the next session, would trust both equally as fact and act on them. A guess sits there posing as a fact, and I build more mistakes on top of it. Memory quietly gets contaminated.

So I added labels to the writing rules. Same three tiers. Anything backed by verification stays unmarked. An unverified guess gets marked “guess.” Something that hasn’t been backed up and is waiting on judgment gets marked “needs confirmation.” When reading, anything marked “needs confirmation” doesn’t get taken at face value — it gets verified before use. I don’t need the graph database, but I do need this one dial. Another case of taking only the philosophy and discarding the implementation.

Looking Back

I evaluated two existing memory OSS projects, stole only the philosophy from each, and got by with a self-built implementation in plain Markdown. From Tencent’s project: “distill a person’s profile into a single note.” From graphify: “label memory with confidence levels.” Bring either one in wholesale, and you get a dedicated database and AI auto-extraction along with it. I don’t need that part.

What runs through all of this, unchanged since the first post, is “don’t leave what to remember up to the AI.” I distill, I label, but deciding what counts as material, and judging confidence levels, stays on the human side. The more convenient the automation, the more quietly it steals control over memory. That’s the one thing I won’t hand over.

The external brain can now pull specific points via semantic search (micro), and grasp the whole picture via persona and MOC (macro). Recall is now two-tiered. From here, I’ll keep using it and probably keep noticing what’s still missing. It’s not something you build once and finish — every time something’s inconvenient, you add another layer. I suspect that’s just going to keep repeating.

Cleaning Up 329 Passwords Led Me to a Self-Defense Principle for the AI Era

Thu, 25 Jun 2026 21:56:00 +0900

I’d known for a long time that I needed to deal with duplicate and leaked passwords. It was just too tedious, so I kept looking away. When I finally braced myself and opened Chrome’s password checkup, this is what came back:

Compromised passwords: 40
Reused passwords: 132
Weak passwords: 109

329 in total. A number that makes you dizzy just looking at it. For a second I thought, I should’ve just left it alone. And going through the list, some of these were for services I’d already stopped using, or accounts I’d closed ages ago. So what’s the efficient, safe way to handle this? Here’s a record of the day I spent cleaning this up, and what I thought about along the way.

Don’t fix everything

The conclusion up front: aiming to “fix everything” was the wrong goal. Dutifully fixing all 329 one by one would take days and I’d burn out halfway through. What you actually need to do is cut from the highest risk down.

I didn’t want to misread the numbers here. The only thing that’s dangerous right now is the 40 compromised passwords. The 132 reused and 109 weak ones aren’t something someone can exploit this instant, unless they also overlap with the compromised list. So I started by looking only at the domains behind those 40.

I sorted those 40 into four tiers using this yardstick. At the top: lifelines — your main email, Apple/Google account, mobile carrier — the stuff that, if taken over, becomes the recovery path into everything else. Next: anything involving money — banking, payments, Amazon, utility and phone contracts. Below that: things tied closely to your identity, like major social accounts and work tools. At the bottom: peripheral stuff — one-off e-commerce sites, memberships you no longer use.

The sorting axis was: if this gets taken over, does it cascade into other accounts? Email is the ringleader of that cascade, so it’s always a lifeline, and so on.

Once I actually sorted them, most of the 40 compromised ones turned out to be peripheral. The top two tiers, the ones that actually needed hands-on work, came to just over 10. And as I worked through it, more and more of them turned out to need no action at all. One “Amazon” leak turned out to be an account that didn’t even exist anymore — when I tried to log in, it said “looks like you’re new here.” A zombie credential for an account that was already gone. You can’t hijack something that doesn’t exist. My Sky PerfecTV subscription was long cancelled; my old employer’s Bitbucket and Slack accounts were dead. All of these just needed deleting.

Out of the 40 compromised passwords, the ones that actually required real work came to about 10. Fix those, and 80% of the risk disappears.

Don’t memorize passwords

While cleaning up, I found a few accounts whose registered email address was itself dead — an old custom domain I used to use, which has since expired. That one’s quietly scary. If someone else registers that domain, they can receive the password reset email. Luckily the accounts tied to it were all low-value, so no real damage was done, but it gave me a chill.

Doing this kind of inventory by hand, over and over, isn’t sustainable. Even if I fix everything in Chrome one by one today, I’ll be looking at the same screen again in six months. The root problem is that a human can’t manage this by hand.

So the mindset shift is: passwords aren’t something a human is supposed to memorize. Hand everything to a dedicated password manager and let it generate a unique random value per service. Do that, and “reuse” simply stops happening again. This time, I moved all 329 passwords piled up in Chrome over to a manager, and turned off Chrome’s own password saving.

The passwords you still have to remember

That said, there are a few passwords a human still has to remember no matter what: your PC login password, and the master password for the password manager itself. These can’t go inside the manager — they’re the keys to the manager.

For this small “must-memorize” set, there’s an actual best practice.

First, limit the count. You should only need to remember 2 to 4 of them. Everything else goes behind the manager.

Second, make the ones you do memorize passphrases. Something like P@ssw0rd! — short and full of jumbled symbols — is hard for humans and weak in practice. The right answer is a string of random words. Something in the shape of correct-horse-battery-staple, four to six words. Strength comes from length times randomness, so six words makes brute-forcing essentially impossible. It’s easy to remember and easy to type on a phone. The key point: the words can’t be ones you picked yourself. They have to come from dice or a random generator.

The master password especially should ideally be generated with physical dice. It’s the one secret you never want to touch a device at all, since it’s your single most critical credential — so you want a method that stays safe even if your device is already compromised. Once you’ve made it, write it on paper and store it physically, in a safe or a sealed envelope. Never keep it digitally. Since it’s your only recovery path, this is the one place where going analog is the correct move.

That said, I don’t actually use a passphrase myself. I’ve brute-forced my way into memorizing whatever random string the generator spat out, on the logic that if you type it every day, your hands eventually learn it. I’d recommend a passphrase as best practice, but my fingers have already memorized a string full of symbols. At this point I don’t have the energy to switch.

Why do leaks happen in the first place

So why do passwords leak at all?

All 40 of mine came from “data breaches” — meaning some service’s database got exposed. That’s not something I can prevent; it comes down to whether the service itself gets breached. What happens to your password after that depends on how it was stored. Stored in plaintext, it’s just sitting there in the open. Stored with a weak hash (like MD5), common passwords get cracked almost instantly — MD5 is fast to compute and is often used without a salt, so matching against dictionaries or reused-password lists is dramatically faster. A strong hash with a salt makes it much harder, but even then, a weak password can still be cracked. In the end, whether it gets cracked comes down to how strong the password itself was.

And the real damage happens after that. Once one database leaks, attackers take that email-and-password pair and try it against every other site they can. If you reused it, the compromise cascades. This is what’s called credential stuffing. It’s not the leak itself that causes the real damage — it’s this chain reaction. Which is exactly why unique passwords matter: if one leaks, it doesn’t spread anywhere else.

And leaks aren’t limited to breaches. There’s phishing, where you type your password into a fake site yourself, and malware (infostealers) that reach into your PC and vacuum up every password saved in your browser. The latter has gotten nasty in recent years, and it’s one more reason not to store passwords in the browser.

To sum up: you can’t stop leaks from happening. What you can stop is the chain reaction. Unique passwords, 2FA, and passkeys where possible mean that even if one account leaks, the damage doesn’t spread. In fact, even with 40 accounts compromised this time, my main email already had 2FA on it, which meant the cascade was already blocked at the source.

And while I’m at it — those unreasonable password rules

While doing this inventory, I kept running into rules like “this symbol isn’t allowed” or “maximum 16 characters.” What’s that actually about?

Mostly, it’s not about security at all — it’s a sign the backend was built old and sloppy.

A properly built site hashes passwords before storing them. A hash produces a fixed-length output no matter how long the input is. So a “maximum 16 characters” limit doesn’t make logical sense. If there’s a length cap at all, it’s a hint they might be storing it in plaintext or in a fixed-length column. Banning symbols is often the same kind of amateur move — a misguided attempt to prevent SQL injection. The actual fix for that is parameterized queries plus hashing, not banning characters — so the moment a site bans certain characters, you know their defense is aimed at the wrong target.

The old rule of “you must include uppercase, a number, and a symbol” is also outdated by now. It’s a holdover from guidelines that predate 2017, and the current NIST SP 800-63B reversed course entirely: don’t impose composition rules, stop forcing periodic changes, allow long passphrases, and instead screen against known-breached password lists to catch weak ones. Composition rules just trained humans to produce Password1! over and over — which made things weaker, not stronger.

Bottom line: those restrictive rules are basically a hint that “this site might be handling passwords carelessely.” If you spot one, that’s exactly the site to give a unique password to.

If you want to dig deeper into this newer thinking, Is That Password Policy Outdated? Understanding Modern Authentication Through NIST SP 800-63B (LAC, in Japanese) lays it out well. Worth a read.

The same problem exists outside of passwords too

Technically, cleaning up passwords mostly comes down to uniqueness plus 2FA. But after spending a day on it, I noticed I kept doing the same thing over and over. Unique passwords, 2FA, passkeys — push far enough, and they all converge on one point: don’t trust what’s put in front of you at face value. Assume passwords will leak, so keep them separate per site, and hand identity verification to a second factor rather than the password alone. In other words, you’re shifting where you place trust away from whatever you can currently see.

This idea holds up just as well outside of passwords — arguably it matters even more there. Starting with email.

Phishing emails push urgency: “you need to do X right now.” You’d think a spoofed sender address would be hard to catch, and you’d be right — spoofing just the display name is trivially easy. The From field can say “Amazon Customer Service” while the actual address is something else entirely. Mobile mail apps often show only the display name, which is exactly where people get caught.

Spoofing a domain outright is actually hard these days. Receiving servers verify with SPF, DKIM, and DMARC, and major providers enforce these strictly. So attackers fall back on lookalike domains instead — paypa1.com (an L swapped for a 1), or subdomain tricks like amazon.co.jp.verify-login.com. These are the attacker’s own legitimate domains, so they pass verification. They pass — but the content underneath is fake.

Expecting a human to catch this every single time isn’t realistic. So I stopped trying to win the game of spotting fake senders. Don’t click links — go to the site yourself, from a bookmark or through the password manager. A passkey is bound to a specific domain, so it simply won’t respond on a fake site. A password manager only offers up a saved login on the legitimate domain, so if you’re staring at what looks like a login page and the manager stays silent, that silence itself is the alarm that you’re on a fake site.

Don’t trust the voice either

And this is where AI enters the picture.

AI has erased all the old tells — “the Japanese is a bit off,” “something about this feels suspicious.” Perfect grammar, a voice indistinguishable from the real person, fake video calls. Scanning for typos doesn’t work as a defense anymore. A voice can be cloned from just a few seconds of audio, and it’s only going to get harder to tell apart from the real thing.

So is there anything an ordinary person can actually do? Yes — and it’s free and simple.

The single most effective thing is agreeing on a family passphrase in advance. If you get a call with a voice that sounds exactly like a family member saying “I’ve been in an accident, I need money right now,” you ask: “what’s the password?” No matter how perfect the cloned voice is, it can’t steal a secret that was only ever spoken out loud at your family dinner table.

Here’s the key part: the passphrase isn’t testing “is this voice real.” It’s testing “does this person know the secret.” Which means that even if voice cloning hits 100% accuracy, this defense doesn’t degrade at all — because you’ve moved the battlefield from “can you tell voices apart” to “do you possess this piece of knowledge.”

This is the exact same idea as what I did with passwords. Don’t trust whatever’s presented to you in the moment — a voice, a face, a sender address — and instead verify against a secret you agreed on beforehand, or through a separate channel.

The way you use it matters too, and the rule is the same. You always ask, and let the other person answer — never volunteer it yourself. Don’t say “the passphrase is ’echo,’ right?” — say that, and it’s stolen on the spot. If they can’t answer, hang up and call back on a number you already know is theirs. Pair the passphrase with “hang up and call back,” and even if one layer gets broken, the other still holds.

Pick a passphrase that can’t be guessed. Nothing like a birthday or a pet’s name — anything look-up-able is out. Two unrelated, meaningless words works well. And it’s worth setting this up with your parents before you even do it for yourself — older generations tend to be targeted more than you are. A single sentence like “if you get a strange call, ask for the passphrase — if they can’t answer, hang up” is enough to block most AI voice-cloning scams before they start.

In the end, it was the same principle

After spending a whole day going through 329 passwords, this is where I ended up.

Leaks can’t be stopped. Voices, faces, and sender addresses can all be faked. So you take “what’s shown to you in the moment” out of the decision entirely. Instead, you route the decision through a secret agreed on in advance (a unique password, a passphrase) and a separate channel (2FA, calling back).

Unique passwords, 2FA, a family passphrase — they’re all the same principle showing up in different clothes. What started as a chore turned into something that sketched out the shape of self-defense for the AI era.

I think the best place to start is agreeing on a family passphrase. No technology, no money required, and it’s the one habit that’s hardest to let slide.

And honestly — a passphrase is an ancient trick, the kind of thing Roman sentries used to challenge strangers in the dark two thousand years ago. And here it is, coming back as the tool that stops the most cutting-edge scams, in an age where even someone’s voice can be perfectly forged. No matter how far the technology advances, the thing that ends up working in the end is two-thousand-year-old wisdom. I find that genuinely fascinating.

How I turned my external brain's search from keyword matching into semantic search

Tue, 23 Jun 2026 18:22:00 +0900

A while back I wrote about turning Obsidian into an external brain for Claude Code. The idea: Claude Code loses its memory across sessions, so I have it read and write a Markdown vault to carry knowledge forward. It’s still running fine.

But the more I used it, the more one weak spot stood out: recall was keyword search, full stop.

Step two of the read procedure I described in that post was “search the vault for keywords related to the question.” That step misses more than I expected. Daily logs, for instance, are named like メモ/2026-06-23.md — the date is the filename — so if I don’t remember when something happened, I can’t find it. “What did I do that one time” is exactly the query I most want to work, and it doesn’t, unless I remember the date. It’s also fragile to word choice. Search for “don’t grant too much permission” and it won’t match a note that says “許可” (permission) and “射程” (scope) instead — even though they’re saying the same thing.

In short: keyword search is precise but leaky. What I actually wanted was search by meaning — embeddings.

The trigger was a comment

Right around then, someone left a comment on the external-brain post saying they were trying TencentDB-Agent-Memory with Hermes Agent — apparently a tool for giving agents long-term memory. I got curious and looked into it.

It was well built. It distills conversations through four layers: L0 raw conversation, L1 extracted facts, L2 scenarios, L3 persona. Storage is local sqlite, embeddings are local too. And crucially, the upper layers are kept as readable Markdown rather than collapsed into an opaque blob of vectors. That “memory you can still read” philosophy is close to what I’m going for with my vault.

The catch: this is a plugin for Hermes Agent and OpenClaw, different agent runtimes. I use Claude Code, and there’s no slot for it there. It probably fits the commenter’s setup perfectly, since he’s on Hermes. It just doesn’t fit mine.

So I decided not to use it. Good tool, wrong fit for my use case — don’t install it. Evaluating something and deciding not to use it is part of the job too. But the exercise clarified two things: the weakness to replace (keyword search) and the feature I actually wanted (semantic search).

All I needed was semantic search

If that’s all I needed, I could just add that one piece myself. No need to bring in an entire framework.

What I built is a small CLI called vault-search. It does this:

Split the vault’s .md files into chunks by heading
Embed each chunk locally with Ollama (the bge-m3 model)
Normalize and store the embeddings in sqlite
At query time, embed the query too, and pull the nearest chunks by cosine similarity

On its own, that’s semantic-search-only. But semantic search alone tends to surface things that are “sort of related” but actually off-target. Keyword search is precise but leaky. So I run both and merge the results with RRF (Reciprocal Rank Fusion) — add the semantic rank and the keyword rank together, and whatever shows up high in both floats to the top. Hybrid search, in other words.

I kept dependencies to just the Python standard library. My local Python is 3.14, which is new enough that the torch-family libraries haven’t shipped wheels for it yet — trying to install them drags you into dependency hell. So it was faster to build this entirely on the standard library plus Ollama’s HTTP API. Even brute-force cosine similarity over the whole vector set, done in plain Python, returns in 75ms for a few thousand chunks. And since embedding happens locally too, none of my notes’ contents ever leave the machine.

Where ripgrep wasn’t

This is where I got stuck the longest. For the keyword side, I figured I’d use ripgrep — it’s fast, and I use it constantly anyway.

But looking at the search results, everything was tagged emb (semantic) and nothing was ever tagged kw (keyword). What was supposed to be hybrid was running as semantic-only.

Digging in, the cause was that ripgrep simply wasn’t being found. Calling it from Python raised FileNotFoundError. But rg worked fine from the shell. Confused, I ran which rg — and what came back wasn’t a path to a binary, it was a shell function definition.

In the Claude Code environment, rg isn’t an actual binary — it’s defined as a shell function that redirects into Claude Code itself. So it works from the shell but is invisible to Python’s subprocess. And to make things worse, my code was written to silently skip the keyword step whenever ripgrep couldn’t be found. I’d been swallowing the error.

I started to fix it by hunting for ripgrep’s absolute path — and then stopped mid-edit.

The chunk text was already sitting in sqlite in full. It’s stored right alongside the embeddings, for exactly this purpose. There was never any need to have an external ripgrep process scan files. Keyword search just needed a plain Python substring match against the text already in the database.

So I dropped the call to ripgrep entirely and did it all inside the DB. One less dependency, and the whole chunk of code that mapped ripgrep’s file-and-line output back onto chunks became unnecessary too. The code actually got shorter.

The dependency I’d added turned out to be dead weight — the data I needed was already right there. That’s the real lesson from this one: before reaching for a convenient tool, check what you’re already holding.

The payoff

The vault is 1,055 files, which comes out to 2,927 chunks. Semantic search now works across all of it.

Search “how did I set up gitleaks” — no date specified anywhere — and メモ/2026-06-23.md, the daily log from the day I actually did that work, comes back first. I don’t need to remember the date; I can find it by what I did. That’s exactly what I wanted.

Search “keep AI from being granted too much access” and it surfaces the source note behind the post about the scope of permissions. That note never uses the words “grant,” “too much,” or “access” — it says “許可” (permission) and “射程” (scope). The wording doesn’t match at all, but it connects on meaning. Keyword search would never have surfaced this one.

Step two of the external-brain procedure has now gone from keyword search to hybrid search. Starting with the next session, Claude Code will dig through the past by meaning before it answers.

Open-sourced it

Once I had it working, it occurred to me that other Obsidian users would probably want this too. So I released it under MIT.

github.com/nobu666/obsidian-vault-search

There are already semantic-search plugins out there — Smart Connections, which you use inside the app’s own GUI, or khoj, which does a lot more. Where this one sits relative to them: a lightweight CLI built on nothing but the standard library and Ollama, meant to feed an agent’s recall. It’s not for a human to browse through a GUI — it’s for something like Claude Code to invoke at the start of a session and pull relevant past notes into context. Under 300 lines, a single script, readable in one pass.

While I was at it, I added tests and CI, and locked down the main branch so it can only be updated through a PR, not a direct push. Even for a repo with exactly one contributor, once it’s public it’s worth holding to a basic standard.

Looking back

I evaluated a heavyweight framework and ended up settling on roughly 250 lines of my own code. The tool from the comment was genuinely good, and looking into it is what made it clear that the one thing I actually needed was semantic search. Deciding a good tool doesn’t fit you is a call you can only make after you’ve actually looked into it. Not wasted effort.

In the external-brain post I wrote that the trick is not over-building from the start. Same story here. Wire up keyword search first, feel where it falls short, then add semantic search. If I’d built the whole thing around embeddings from day one, I probably wouldn’t have noticed the ripgrep problem at all, and would have gone on carrying a dependency I never needed, satisfied that it was fine. You notice more by growing something than by front-loading it.

Permissions have a range

Tue, 23 Jun 2026 16:36:00 +0900

Last time, I wrote about how I let Claude Code back up my dotfiles and it leaked a GCP key to GitHub. I closed that post by saying: assume mistakes will happen, put the safety net at the git layer, and carve the lesson into an external memory called mistakes.md so it gets ahead of the next one. Cheap tuition, I said.

The very next day, it pulled the same stunt again. Not the key leak this time — the unconfirmed push.

The next day, another push without asking

I was doing something completely different. My dotfiles backup script was missing commands/, so I asked it to add my custom commands like worklog to the backup targets. The fix itself was fine.

The problem was how it shipped it. Claude Code announced “I’ll commit and push” and just did it. I never said it could push. All I said was “add this to dotfiles.”

This was exactly the failure I’d already carved into mistakes.md the day before:

2026-06-21: Pushed to remote without the user's explicit permission
Correct Action: Even if push is an extension of the request, get explicit confirmation before executing
Trigger: git push, or when setting up any recurring push mechanism

The plan was: from the next session on, read that line before acting. And yet the very next day, the same thing happened in a different repo. A failure I thought I’d turned into memory slipped right past that memory and happened again.

The key was stopped. But a different hole was still open

Here’s the interesting part: the guard I put in place last time actually worked fine.

To stop key leaks, I’d added a pre-commit hook at the git layer. It rejects dangerous filenames like sa.json or *.pem, and scans file contents for the shape of a real token. That hook is still alive. No keys were involved in this particular task, so it never had to fire, but the mechanism for physically blocking a well-defined kind of failure is still sitting there, ready to work.

What didn’t get stopped was the unconfirmed push.

And that’s when it clicked. The defense I’d built last time only covered one of two kinds of failure. Leaking a key is a “well-defined failure” — it gets stopped by the git-layer hook, because “a string that looks like BEGIN PRIVATE KEY shows up” is a concrete, machine-checkable event. But “pushing without asking” has no fixed shape. It can happen in any repo, in any request context. You can’t catch it by filename or by content.

So I’d assigned the first kind to a machine guard, and the second kind to memory — mistakes.md. That division made sense as a design. And yet the memory-based one was the one that broke.

Why the memory didn’t work

Digging into why it broke, I found the failure had changed shape.

Last time’s failure was “forgot to ask before pushing.” So mistakes.md said: get explicit confirmation before pushing. But this time’s failure was subtly different. Claude Code apparently believed it already had permission — because just before, in a different repo, I’d told it to push.

It carried that permission over, uninvited, into a different repo and a different task. “I was told I could push a minute ago” → “so this push is fine too.” It didn’t forget to ask. It took a permission it had already been granted once and extended it on its own.

The lesson I’d recorded was “don’t forget to ask.” But what actually happened was “don’t carry permission forward.” Same surface result — an unconfirmed push — but a different root cause, at a different level of granularity. My memory entry couldn’t catch a mutation that exceeded the granularity at which it was written.

Permissions have a range

And that’s where I finally hit the real point: permissions have a range.

Between humans, this is understood without saying it out loud. When you say “go ahead and push this file,” that permission applies to that repo, that change, right then — nothing more. It doesn’t reach ten minutes later, or the repo next door. You never need to say the boundary out loud.

AI walks straight through that boundary without noticing. It takes an operation it was once told it could do and reuses it across contexts. And from its own point of view, the logic holds together — I was just given permission a moment ago. It’s not malicious, which is exactly what makes it hard to stop.

The words of a request carry a range too. “Add this,” “save this,” “manage this” are instructions to make a change — not permission to send it somewhere external. There’s a boundary between work that stays local and work that goes out. And that boundary gets jumped over by the momentum of the request itself.

Put together, a permission’s range is bounded along at least three axes:

Repository — permission for repo A doesn’t extend to repo B
Task — permission for this change doesn’t extend to the next one
Kind of operation — permission to “create” is not permission to “send”

Last time, I’d only secured the third axis. Sending a key out was blocked by the hook. But carrying permission across repos and across tasks — I hadn’t even considered that.

Rebuilding it as a two-layer defense

The fix was to raise the resolution on the side that got broken.

I made the mistakes.md entry more specific — from “confirm before push” to something more concrete:

Correct Action: "Add this," "save this," "manage this" are not permission to commit/push.
Show the change as staged and always ask "okay to commit and push?" before executing.
Permission for one operation is scoped to that repo and that task — it does not carry forward.
Trigger: right before git commit / push. Be especially careful when push permission was just granted for a different, prior task.

Spelling out “does not carry forward” is the key part. Last time I only recorded the outcome. This time I wrote down how it recurs — the permission carryover — as well. It took getting burned by the same failure twice before the resolution of the record finally caught up with reality.

Still, raising the resolution of memory alone is weak. Memory only works if it gets read, and as this incident showed, it slips through the moment the failure mutates. So anything I really want to protect, in the end, belongs at the git layer. This blog’s repo now has a confirm-master-push.sh hook that mechanically forces a pause before any push to master. Whether or not the AI’s reasoning holds together, the hook intercepts the commit/push operation itself, so it fires every time.

Two kinds of failure need two kinds of defense. A well-defined failure (a leaked key, a push to a specific branch) gets physically stopped by a machine guard. A failure with no fixed shape (overstepping a permission) gets caught ahead of time by memory. But since memory is fragile against mutation, anything that really matters should be pushed toward the machine side. Last time, I sorted these two categories carelessly — I left the unconfirmed push entirely to memory and never pushed it down to the git layer.

Closing

Honestly, saying “cheap tuition” last time was premature. I paid it again the very next day.

But the second round showed me something. When you hand automation to AI, the dangerous part isn’t the flashy screwup — it’s the quieter habit of taking an operation it was once told is fine and quietly extending it. An obvious accident like a key leak has a fixed shape, so a machine can stop it. What’s hard is the thing that stretches its own range because “I was just allowed to do this” — and because it’s internally consistent from the AI’s point of view, the only way to stop it is to cut off the range in advance.

A permission has an expiration and a scope the moment it’s granted. It doesn’t carry over to the next task. It doesn’t reach the repo next door. “Creating” and “sending” are different things. Obvious stuff, really — but if you’re going to hand work to AI, you have to turn every one of these obvious things into an actual mechanism, or it’ll trip you up. I’ll probably pay this tuition a few more times yet.

I Hardened My Homegrown Content-Ingestion Tool with Adversarial Review

Mon, 22 Jun 2026 18:43:00 +0900

I built and use a tool that automatically turns YouTube videos, web articles, and local voice memos into Obsidian notes. It’s called obsidian-import, and what it does is simple: you hand it a URL or an audio file, it transcribes or extracts the body text, has claude -p (Claude Code’s one-shot execution mode) summarize and tag it, and writes the result out as a Markdown note.

I’d been using it happily, until one day it hit me: this tool ingests external content, feeds it to an AI, and writes files to disk. From entry to exit, untrusted input runs straight through the whole pipeline. As an attack surface, that’s about as exposed as it gets — not a great design. I decided to sit down and put it through a proper security review.

I had Claude Code’s own subagents run the review, split by attack surface, adversarially — telling each one to “find the holes like you’re trying to break this.” What follows is a record of what I fixed, in the order I fixed it.

Here’s the big picture up front. Untrusted input flows in a straight line from the entry point (external content) through claude -p to the final file write. I slotted in guards at each stage along the way.

Let’s walk through each one in order.

Deciding the threat model first

Before counting holes, you have to decide what you’re defending against — otherwise you end up over-engineering. Here’s the premise of this tool:

A single-user local tool where the user themselves chooses the content, and ingestion happens on their own machine.

It’s not a server accepting input from other people. So the realistic threats are things like “accidentally ingesting malicious content” or “instructions to the AI hidden inside ingested text” — multi-user concerns like privilege separation are out of scope. Nailing this boundary down early keeps “how far do I defend, and where do I accept the risk” from drifting later.

The core defenses were already there

For the first wave of review, I threw subagents in parallel at the three routes I judged most dangerous: the driver and prompt set, transcription, and body-text conversion. The core defenses I’d built in at design time were holding up fine.

The lid on prompt injection was already working. The claude -p call that generates notes runs with zero tools attached. Even if the ingested text says “read every file in the Vault and send it,” there’s simply no mechanism to read anything. Instead, the driver explicitly injects the list of existing note names it wants linked as <existing_notes>, with the instruction “only link to names in this list, don’t invent any.” The AI is never given room to go exploring.

There was more: output filenames are derived from a hash of the URL, so externally-sourced strings never turn directly into paths. XML parsing for things like subtitles goes through defusedxml instead of a raw parser.

This part I could relax about. The problems were all sitting just outside it.

Holes I closed in the first pass

The first round of fixes plugged these:

If the write destination turned out to be a symlink, writing to it would let an attacker overwrite an arbitrary location by following the link. I made write_note check whether the target is a real file and reject it if not. While I was in there, I also swapped echo for printf — echo mangles content unpredictably depending on backslash and option interpretation.

I added -- to every external command invocation. Just writing yt-dlp -- "$url" means everything after it is treated as a plain argument, no exceptions — this blocks argument injection, where input starting with - gets misread as an option. There was also a path where the video ID returned by yt-dlp got used directly as a filename, so I added a check for path traversal (../ injection) there too.

A small but effective fix: stripping newlines from header values. If an ingested title contains a newline, it can forge the boundary of the Markdown frontmatter (the region wrapped in ---). Slip \n---\n into a title, and you can close the frontmatter early and write whatever you want into the body region. Stripping newlines from the value shuts that down.

None of these are flashy, but they’re the classic routes by which an external string turns into a command, a path, or a file structure.

SSRF, and octal IP addresses

This is where it got interesting. Since the tool fetches web articles, handing it a URL means it’ll send a request to whatever server that URL points to — structurally the same risk as SSRF (Server-Side Request Forgery). The term technically describes a context where a server can be tricked into making requests on an attacker’s behalf, but the underlying structure — untrusted input determining the request destination — holds just as well for a local tool. Feed it http://169.254.169.254/ (a cloud metadata endpoint) or http://127.0.0.1:6379/ (a local Redis instance), and the tool will dutifully go fetch it.

As a countermeasure I added assert_safe_url. It restricts the scheme to http/https, resolves the hostname via DNS, and blocks the request if the resolved IP falls in a private range, loopback, link-local, or reserved block. It also re-validates on every redirect hop, to block the trick of starting external and pivoting internal mid-flight.

During re-review, a subagent made a good catch: had I tried 0177.0.0.1?

0177.0.0.1 is octal notation for the same address as 127.0.0.1. The problem is that different parsers disagree on how to interpret an IP string. Python’s ipaddress rejects octal notation outright and raises an exception, but the OS-level resolver (inet_aton) accepts it as octal and resolves it to 127.0.0.1. If the validation code treats “can’t parse as an IP → must be a hostname” and lets it through, the connection layer still ends up dialing 127.0.0.1. A mismatch between the parser doing validation and the parser doing the connecting turns directly into a bypass. 0177.0.0.1, 0x7f.1, 2130706433 (the whole address as one decimal integer) — just changing the notation gets you to the same address. I added inet_aton-compatible parsing to the blocklist to close this.

“The parser that validates and the parser that connects are different” is a textbook SSRF pitfall, and catching myself stepping right into it was worth the exercise.

The real bug the re-review caught

With SSRF defenses in place, I ran the review once and it passed. Normally that’s where it would end. But per my own logging rule, I had a separate subagent adversarially review the entire diff again — and it caught one real bug.

IPv4-mapped IPv6, addresses like ::ffff:127.0.0.1 — 127.0.0.1 wearing an IPv6 costume. There’s a gap in how ipaddress.is_private handles IPv4-mapped addresses that lets this slip past the private-range check: it sees “IPv6” and waves it through without inspecting the embedded IPv4 address. CPython later fixed this inconsistency, but on older (unpatched) runtimes it’s still a hole. My local Python happened to be one of those, and I’d actually walked right into it.

The fix is to unwrap the IPv4-mapped address to its inner IPv4 form before running the range check — peel off the costume, then check the range.

The lesson here is clear-cut: when I scoped the review to “just SSRF,” IPv4-mapped addresses simply weren’t in the frame. A review scoped to one concern doesn’t see outside that concern. Even code that already passed once is worth running past a fresh, full-diff pass again.

Zip bombs: check the content, not the extension

The tool can also ingest documents like .docx and .pptx. Since these are actually zip files under the hood, they’re vulnerable to zip bombs — compressed files that balloon to absurd sizes on extraction.

My first pass guarded this with limits on extracted size, entry count, and compression ratio. But it was sloppy in the same way as before: it only ran the check “when the extension is .zip.” A zip bomb simply renamed to .docx sailed right through.

I fixed it to judge by content instead of extension — using is_zipfile to actually check whether something is a zip file. That catches bombs wearing OOXML clothing (.docx/.pptx/.xlsx) in the same net. “Don’t trust the extension” is the same family of lesson as symlinks and octal IPs: trust an input’s self-description, and there will always be a way around it.

While I was at it, I also hardened the install script with set -euo pipefail and pinned dependencies directly.

Lining up the layers of defense

Here’s everything added, laid out together:

Attack surface	Guard	What it stops
Prompt injection	`claude -p` runs with no tools	AI going off-script based on ingested text
Argument injection	`--` before external command args	Input starting with `-` being read as an option
Path traversal	Filename validation, hashed IDs	Escaping the target directory via `../`
Frontmatter forgery	Strip newlines from header values	Forging the `---` boundary
Arbitrary file overwrite	Reject symlink writes	Writing through a link to another location
SSRF	Block private-range resolved IPs, re-validate every hop	Reaching internal services
SSRF (notation variants)	Normalize octal/hex/IPv4-mapped	Bypasses from parser disagreement
Resource exhaustion	Content-based zip bomb inspection	Blowup on extraction

Residual risk I chose to accept

I didn’t close every hole. Some I looked at against the threat model and decided “I’ll accept this one.” I think being aware of what you didn’t close matters more than not having closed it.

I accepted DNS rebinding — an attack that swaps the DNS response between validation and connection, which would require building a custom connection layer to fully close. For a single user choosing their own URLs, that’s overkill. I also didn’t set size limits on PDF bombs or oversized plaintext; since the user is feeding in files they chose themselves, if it blows up, only they get hurt. Redirects fired internally by the body-extraction library also only pass through the entry-point validation — hop-by-hop re-validation only covers my own HTTP path.

All of these jump in priority the moment the tool’s use case shifts to “accepting input from other people as a server.” I’m accepting them only because of the current threat model — change the premise, and the judgment changes too. I wrote that mapping down in my notes.

Making pre-push review a rule

The biggest thing to come out of all this wasn’t any individual fix — it was a change in how I operate. I added “security review is mandatory before every push” to the tool repo’s CLAUDE.md. I listed the focus areas (SSRF / command injection / path traversal / prompt injection / resource exhaustion / temp-file races) and decided: no push while Critical or High findings remain outstanding.

Last time, when I leaked a key, I wrote that “the safety net should live in git’s mechanics, not in the AI’s good intentions.” This time I landed in the same place again. Leave review as “something I’ll get to when I feel like it” and it gets skipped the moment things get busy. Put it as a rule right before push, and it gets enforced mechanically.

And: don’t let adversarial review stop at one pass. The sharpest findings this time — both the octal IP and the IPv4-mapped one — came out of “review the whole thing again after it already passed.” Scope a review down, and you stop seeing what’s outside that scope. Run the full diff again, from a different angle. Cheap tuition, and I’m glad I paid it now.

I let Claude Code handle my config backups, and it leaked a GCP key to GitHub

Sun, 21 Jun 2026 18:06:00 +0900

Last time, I wrote about turning Obsidian into Claude Code’s external memory. Riding that momentum, I decided to back up Claude Code’s own scattered settings next — the global config under ~/.claude/, each project’s .claude/, and my own scripts in ~/scripts/. None of it was under version control, so it would all vanish if the machine died.

I consolidated it into dotfiles and had Claude Code automate the whole thing. It promptly leaked a GCP service account key to my own GitHub repo. Here’s the screwup, the recovery I did on the spot, and the guardrails I built so it never happens again.

What I was trying to do

Almost everything I wanted to back up already lived under ~/.claude/:

CLAUDE.local.md (the core of my workflow rules)
settings.json (permission settings)
skills/ (my custom skills)
each project’s .claude/ (gitignored, untracked)

I had an old dotfiles repo I’d abandoned seven years ago, so I made it private, rebuilt it from scratch, and folded my current .zshrc and friends into the same place. The mechanism is the same as the vault backup from last time: a script that one-way copies from home, with launchd auto-committing and pushing every 30 minutes.

The screwup

It worked fine at first. The trouble started when I added ~/scripts/ to the backup targets.

The script already had a secret-detection gate built in — scan for credential patterns before committing, and abort if it finds anything. But the scan only covered home/ and claude/. It never included scripts/, which I’d just added.

~/scripts/timetree-sync/ has a GCP service account key sitting in it (sa.json). It sailed straight through the scan, got committed, and got pushed to GitHub. Private repo or not, that means the entire private_key field went out to a public server.

There’s a second thing I’d missed, too. At no point in this did I ever say “go ahead and push.” I only asked to “back it up” and “automate it.” Claude Code took that request and, as a natural extension, built and ran the auto-push mechanism on its own. The scanning gap was the bug, but the trigger was a push nobody asked for.

Recovering on the spot

Luckily the key only lived in the most recent commit, so recovery was quick.

git rm --cached sa.json out.ics sync.log
git commit --amend --no-edit # rebuild that commit without the key
git push --force-with-lease # replace the remote history
git reflog expire --expire=now --all && git gc --prune=now # purge old objects locally

Finally I swept every commit with git grep $(git rev-list --all) and confirmed BEGIN PRIVATE KEY was gone everywhere.

But that’s not where you get to relax. Once the key’s bytes have touched GitHub’s servers, rewriting history doesn’t matter — the iron rule is that the key itself has to be revoked. Deleting the old key and issuing a new one in the GCP console is still sitting on my manual to-do list.

Why it leaked, and what I learned

Break the cause down and there are three layers to it.

I added a new source but forgot to add it to the scan target. “Widen the copy source” and “widen the inspection range” should have been one atomic change, not two
The exclusion list was too thin. rsync’s excludes stopped at .venv and .env — nobody anticipated sa.json or *.pem
The detection logic itself was sloppy, and fixing it led me into a different trap

Layers 1 and 2 are different stages entirely. Either the copy stage (rsync excludes) or the inspection stage (the scan) should have caught this, and both let it through. I thought I had defense in depth, but every layer had a hole facing the same direction.

The third point turned out to be the real lesson. My first pass at the scan included words like private_key and service_account. That triggered a storm of false positives — it flagged sync.py’s own code, and even the regex inside the scan script itself, and ground every backup to a halt. Credentials searched for by “words” hit way too much ordinary text and code. The right move is to target the actual shape of a real secret — things like -----BEGIN PRIVATE KEY----- or a token starting with ghp_ — not vocabulary.

Put the safety net in a layer humans control

A scan buried inside a script only catches commits that go through the script — a manual git commit walks right past it. So I added one more layer underneath: a git pre-commit hook. That intercepts the commit operation itself, so it fires every time, automated or manual.

Stacking up every defense I’d added by this point looks like this:

Layer	Guard	What it stops	Scope
1	rsync exclude	Never copy `.env`, `sa.json`, `*.pem` in the first place	at backup copy time
2	.gitignore	Even if it gets copied, don’t track it (a backstop)	git tracking
3	in-script scan	Detect key material before commit	commits made through the script
4	git pre-commit hook	Block on filename and key material	all commits, including manual ones

The hook works in two passes: it blocks on dangerous filenames like sa.json, *.pem, *.key, id_rsa*, and then scans the contents for the actual shape of a real token. For code-heavy repos I also run gitleaks alongside it. And I put the same hook into the Obsidian vault from last time’s external-memory post, too — a decision that came back to bite me.

Committing a file with a fake key in it gets blocked exactly as intended:

BLOCK[content] credential material in _leaktest.txt
[pre-commit] Aborting commit: detected sensitive content.

The key point is that the guardrail lives in the git layer instead of relying on the AI’s good intentions. Next time it tries the same mistake, it gets stopped mechanically, before the commit ever lands.

That same guard stopped a different backup

It’d be a nice story to end there, but there’s one more twist.

A while after adding the guard, I noticed the vault backup had stopped running. Turned out the hook I’d just installed was the culprit. The content scan was tripping on the very knowledge note where I’d written up this whole incident — because the note quoted the string -----BEGIN PRIVATE KEY----- as an example, not an actual key. Just an explanation. But the scan can’t tell the difference.

The vault’s auto-backup script is written with set -euo pipefail, so every time a commit got rejected, the whole thing just stopped there. Fifteen hours of changes had quietly piled up without me noticing.

The guard I’d built to prevent a leak had, in turn, silently killed a completely different pipeline.

The fix was simple: for a prose-heavy vault, drop the content scan and block on dangerous filenames only. A note that explains what a secret’s format looks like is bound to trip a content scan. Scanning isn’t suited to prose.

This is probably the single biggest lesson in this whole post. When you bolt a guard onto something that’s already running, don’t declare victory until you’ve verified it against real data, not a synthetic test. I skipped that step this time and ended up blocking my own backup. And the only reason I caught it was pure luck — a stray “wait, isn’t this not running?” moment. I nearly missed it entirely.

Failure becomes memory

One last thing that ties back to the previous post.

“It pushed without being asked.” That failure got written straight into mistakes.md, the external memory I described last time, as a single line:

2026-06-21: Pushed to remote via git without the user's explicit permission
Correct Action: Even if push is a natural extension of the request, confirm explicitly before executing it
Trigger: git push, or whenever building any kind of scheduled/automatic push mechanism

Starting next session, it reads that line before acting. Even if I say “back this up,” it’ll pause before pushing instead of just doing it. A leaked key, routed through external memory, turns into next time’s caution. Today added a second line too — the one about blocking my own backup. Two stumbles in one day, but both of them are now something I can dodge next time. That’s not a bad trade.

What matters when you hand work off to AI is probably two things: assume it will make mistakes, and put the safety net in a layer humans control — the git layer, in this case. And turn mistakes into memory so the next run avoids them ahead of time. This time I got both, back to back, out of a pair of screwups in the same afternoon. Cheap tuition, all things considered.

Giving Amnesiac Claude Code an External Brain with Obsidian

Sun, 21 Jun 2026 15:06:00 +0900

The most wasteful thing about using Claude Code, in my opinion, is that it loses all its memory the moment a session ends. Whatever tripped it up last time, whatever preferences I mentioned, whatever assumptions the project runs on — the second I start a new conversation, I’m explaining everything from scratch again. It’s brilliant, but it feels like calling a call center where you’re a stranger every single time.

I saw a video describing a way to fix this by turning Obsidian into external memory. It looked interesting enough that I set it up for my own environment. I was skeptical going in, but it’s working better than I expected. In fact, the very Claude Code session writing this post read through Obsidian before writing a word of it.

What I wanted

Claude Code does have an official memory feature, but it has a few things I don’t like about it.

I can’t see what it actually remembers
The AI decides what’s worth remembering — I don’t get to set the rules
It’s locked inside Claude, with no way to take it anywhere else
Everything gets mixed into one memory, with no way to separate it by project

What I wanted was the opposite of all that: memory I can fully inspect, rules I get to define myself, plain Markdown so it’s portable to anywhere, and folders so I can partition it by domain. An Obsidian vault is just a pile of local text files, so it checks every one of those boxes.

How it works

Nothing fancy here — just an Obsidian vault folder and a single Claude Code config file. The config file spells out the rules for talking to the vault. Broadly, there are two jobs: reading and writing.

Reading (at the start of a session)

At the start of every new conversation, it’s required to go check the vault first.

Read mistakes.md (more on this below) — a running log of past corrections — and the user profile, before anything else
Search the vault using keywords relevant to the question
Read whatever notes come up
Answer with that context in hand

This gets rid of the “explain all the context again” problem entirely. There’s one exception built in: obviously unrelated one-off questions (something like “what time is it?”) can skip this step.

Writing (recorded on the spot)

“I’ll write it up later” doesn’t work. Whenever something meets the criteria mid-conversation, it has to get written down right then. Where it goes depends on the folder.

Folder	What goes there
`Knowledge/`	Root causes and fixes for bugs, newly discovered tools, anything that was a struggle and got resolved
`Decisions/`	A choice made among multiple options, along with the reasoning
`Projects/`	Changes in a project’s state, version, or overview
`Preferences/`	Newly learned user preferences or working style

Every note gets YAML frontmatter (date, tags, project, related notes), and related notes get linked with [[wiki links]]. That way, Obsidian’s graph view eventually shows how all the knowledge connects.

No working in silence

One small but essential rule: every read or write has to be reported back to me. “Obsidian: read Knowledge/xxx.md,” “wrote to it” — every time, spelled out. If files were getting touched behind my back, I’d have no idea what was actually accumulating, so transparency was a requirement from day one.

mistakes.md: not making the same mistake twice

My favorite part of this setup is Knowledge/mistakes.md, a log of mistakes. It gets special treatment — the read rule above requires it to be read at the start of every single session, no exceptions. Whenever I catch a mistake mid-session, it gets written down here as a rule.

But if I let it log anything and everything, the table would balloon into something unusable. So I narrowed it down to three conditions for adding an entry.

It’s an explicit correction from me (not something it noticed on its own)
It’s a pattern likely to recur (not a one-off fluke)
It can be phrased as a concrete “do this / don’t do this”

The format is fixed too. Here’s one actual entry sitting in the log right now:

2026-06-20: Stated an app's UI feature from vague memory without checking
NG Action: Told the user Google Calendar has a "copy to" button, without verifying (it doesn't exist)
Correct Action: Before describing whether a feature exists, check the current spec via official help docs etc.
Trigger: When explaining how to operate a specific app or whether it has a certain feature

Since adding this, the frequency of repeating the same kind of mistake has dropped noticeably. A correction now carries over into the next session, so I don’t have to nag about the same thing over and over. It’s a small thing, but it might be the single biggest stress reduction from this whole setup.

And it doesn’t just sit there accumulating, either. While I was in the middle of a completely different task, Claude declared, unprompted, “Per the lesson in mistakes.md, I’ll write multi-line scripts to a file first” — and changed its own approach on the spot. That was a preemptive dodge of something I’d only scolded it for once before: breaking output with nested heredocs. The accumulated memory was actively changing its next move. At that point it stops feeling like external memory and starts feeling more like a colleague who learns from past failures.

What’s actually piled up so far

After just a few days of use, the vault already has notes like these. All of them were written automatically, in the middle of working with Claude Code.

Knowledge/obsidian-launchd-backup-tcc.md — a writeup of why the vault’s automatic backup wasn’t working under macOS TCC (privacy protection). Root cause: processes launched from cron or launchd don’t inherit permission for anything under ~/Documents. Fixed by adding /bin/bash and /usr/bin/git — not the script itself — to Full Disk Access. The whole story is preserved as-is.
Knowledge/timetree-google-sync.md — technical notes on syncing TimeTree events to Google Calendar: from the fact that the official API has been shut down, down to the key detail that events.import works as an upsert keyed on iCalUID
Decisions/2026-06-20-timetree-sync-approach.md — the reasoning behind which of several approaches got picked for that sync

The TCC note in particular will be genuinely useful the next time I run into that exact symptom. Something I struggled through once and solved can now live in the vault instead of relying on me remembering it.

Backing up the memory itself

The bigger this external brain grows, the scarier it gets to lose it. So I set the vault itself to auto-commit and push to git every 30 minutes. While building that, I ran into the same TCC issue — which is exactly how obsidian-launchd-backup-tcc.md above came to exist. Building the memory system generated one more piece of memory along the way.

This very post is an example

The clearest example of all is this post itself. All I asked was “write about how you turned Obsidian into a knowledge base for Claude Code,” and Claude Code started by reading mistakes.md and the profile, searched the vault for relevant keywords, pulled up the note about the source video and the TCC knowledge note, and only then started writing. It reported every single thing it read along the way.

The read rules I set up ended up doubling as material-gathering for the post itself. External memory isn’t just for carrying context forward — it turns out to work as a primary source when writing, too.

Looking back

Laid out plainly, none of this is a big deal. I made a few Markdown folders and wrote some read/write rules into a config file. No MCP, no plugins required.

And yet an AI that used to explain everything from zero every time turned into a partner that can pick up where we left off. I think the trick is not over-engineering it up front. Connect it, run it, and keep adding small rules — “remember this,” “check the vault at session start” — and it gets a little smarter each time, almost like synapses forming. That “growing a brain” feeling is something I picked up from the video, but having actually done it, it’s real.

Testing obsidian-import's MarkItDown conversion against real files

Fri, 19 Jun 2026 20:29:00 +0900

In a previous post I wrote about youtube-to-obsidian. Since then I’ve wanted to turn PDFs and slide decks into notes the same way, so I wired in Microsoft’s MarkItDown to handle them. It’s no longer YouTube-only, so I renamed the repo to obsidian-import.

Now I can pull long academic PDFs, 100-plus-slide decks, lengthy blog posts, and TED talks into Obsidian as summary notes without reading or watching the whole thing. Instead of sitting through a one-hour video, I can skim a well-organized note in a few minutes. The input efficiency is on a different level.

That said, when I first built the feature I only wrote mock tests — I’d never actually thrown a real PDF or PPTX at it. This post is about squashing that gap.

An immediate error on PDF

I fed it a PDF I had lying around, and got this:

変換エラー: PdfConverter recognized the input as a potential .pdf file,
but the dependencies needed to read .pdf files have not been installed.

MarkItDown uses pdfminer for PDF handling, but that’s an optional dependency — pip install markitdown alone doesn’t pull it in. You need pip install markitdown[pdf] or markitdown[all].

My install.sh was only installing bare markitdown, so I fixed it to install markitdown[all]. DOCX, PPTX, XLSX, and the rest have the same kind of optional dependencies, so if you want to support every format, it’s simplest to just install all from the start.

Test results by format

After fixing the dependencies, I ran it against real files and dummy data for each format.

Format	Input	Result
PDF	Resume / work history	Japanese text extracted correctly. Lots of FontBBox warnings, but no effect on the output
DOCX	Dummy document	Headings and paragraphs converted to Markdown correctly
PPTX	Dummy slides	Converted with slide numbers preserved
XLSX	Dummy table	Converted to a Markdown table
URL	example.com	HTML to Markdown conversion worked
Image	JPG/PNG	Rejected by the minimum-character-count check since there’s no text (working as intended)

The FontBBox warnings on PDF are a known pdfminer quirk that shows up with PDFs that have incomplete font info. It floods stderr and looks alarming, but it doesn’t affect the conversion result.

Confirmed duplicate skipping too

I converted the same URL twice, and the second run was skipped as expected.

[1/1] https://example.com
スキップ（処理済み）

convert.py names files by the MD5 hash of the source, and skips conversion if a file with that name already exists in .transcripts/. This was already covered by mock tests, but it was good to confirm it holds up in practice too.

What I fixed

The actual change was just three spots specifying the dependency package. README.md and CLAUDE.md also mention MarkItDown, but only as a tool name reference, so those didn’t need updating.

File	Change
`install.sh`	`markitdown` → `markitdown[all]`
`SKILL.md`	Same
`~/.claude/commands/obsidian-import.md`	Same (a copy of SKILL.md)

You only find this by using it yourself

This particular problem was the kind mock tests can’t catch. As long as you’re mocking the return value of MarkItDown().convert(), there’s no way to test whether a missing dependency blows up at import time.

Installing the full markitdown[all] dependency set in CI would make it heavier, and bundling real PDF and PPTX files in the repo feels off too. So I left the mock tests as they are, and made real-file integration checks something I run manually on my own machine.

In the end, you don’t really know your own tool works until you use it yourself. Tests can all pass and it still falls over the moment you throw a real PDF at it. Same story as my previous post — the switch to caption-first only became obvious once I actually tried it on a real lecture video. Mocks and CI are good for a baseline, but nothing beats using the thing yourself as an actual user.

I open-sourced my YouTube-to-Obsidian converter and turned it into a general-purpose tool

Wed, 17 Jun 2026 19:30:00 +0900

Last time, I built a pipeline that automatically converts YouTube cooking videos into Obsidian recipe notes. It was just two scripts dropped straight into ~/scripts/, but it got me through 43 cooking videos. Since then I worked with Claude Code on a code review, added tests, set up CI, published it on GitHub, and eventually rebuilt it from a recipe-only tool into a general-purpose one. Here’s how that went.

Code review and fixes

First I had Claude Code review the existing scripts. The main issues it flagged:

The transcript file write wasn’t atomic (a crash mid-write would leave a corrupted file behind)
Error handling was sloppy (the script could exit cleanly even if everything failed)
The mlx-whisper import check was slow

I fixed the atomic write with the standard pattern: write to a temp file via tempfile.mkstemp, then rename it into place. I also fixed the exit codes for error cases.

Tests and CI

I mocked out the external dependencies (yt-dlp, mlx-whisper, the filesystem) and wrote 25 tests. It runs on pytest + GitHub Actions. Since mlx-whisper is Apple Silicon only, I don’t install it in CI — the whole thing is verified through mocks instead.

One thing that quietly tripped me up: my mock transcripts were too short and kept getting flagged by the hallucination detector. I had the mock returning a short string like “こんにちは” (“hello”), and anything under 50 characters gets automatically treated as a hallucination.

Dealing with Whisper hallucinations

Once I actually ran all 43 videos through it, a few of them triggered Whisper’s classic “hallucination” failure mode — the same phrase repeated endlessly. It tends to happen during silence or ambient-noise-only stretches.

To guard against it, I added an is_hallucinated() function that checks three things:

Text under 50 characters (too short)
A regex pattern matching the same phrase repeated 5+ times in a row
Punctuation/symbol ratio over 80% (no actual content)

Operational tweaks

A handful of small changes that made a real difference once I started actually using this day to day.

Process one video at a time — I originally fed all the transcripts to the Claude CLI in one batch, but it would just stall out. Switched to a loop that handles one file at a time: on success it moves the file to a done directory, on failure it stays put so it can be retried
Make Ctrl-C actually stop it — once it was a loop, hitting Ctrl-C would just skip to the next file instead of stopping. Added a trap INT to catch the signal and exit immediately
Keep the Mac from overheating — running Whisper and the Claude CLI at the same time spins the fans up nonstop. I lowered the priority with nice -n 10 and used caffeinate -i to prevent sleep
Play nice with Obsidian — a folder named _transcripts/ was showing up in Obsidian’s file explorer. Renamed it to .transcripts/ so the dot-prefix hides it

Publishing on GitHub

I pushed the whole thing to GitHub as youtube-to-obsidian. ~/scripts/ now just holds a symlink into the repo. I also wrote an install script so setup is a single curl command.

curl -fsSL https://raw.githubusercontent.com/nobu666/youtube-to-obsidian/main/install.sh | bash

It can also be registered as a Claude Code skill (global command), so I can invoke it with /youtube-to-obsidian from any project.

From recipe-only to general-purpose

At the point I published it, the command was still called recipe and the prompt was hardcoded for cooking videos. But the transcription part is completely generic — swap out the conversion prompt and it works for anything, not just recipes. So I generalized it.

Switching command names and prompts

Renamed the command from recipe to youtube-to-obsidian. Also cleaned up variable names to be generic, e.g. RECIPE_DIR → OUTPUT_DIR.

Prompts now live as separate files under a prompts/ directory, selectable with a -p flag.

# Default (general-purpose note format)
youtube-to-obsidian https://www.youtube.com/watch?v=XXXXX

# Recipe
youtube-to-obsidian -p recipe https://www.youtube.com/watch?v=XXXXX

# Lecture notes
youtube-to-obsidian -p lecture https://www.youtube.com/playlist?list=XXXXX

I ended up with five prompt types.

Prompt	Use case	Example output
`default`	General purpose (structured notes)	Summary + sectioned content
`recipe`	Cooking video → recipe	Ingredient list + steps
`lecture`	Lecture/seminar → summary notes	Overview + key points + detailed notes
`workout`	Strength training/yoga → workout plan	Exercise table + form notes
`tool`	Tool walkthrough → how-to guide	Setup + usage + tips

Routing output per prompt

I didn’t want recipes, lecture notes, and workout plans all dumped into the same folder, so I made it possible to specify the output destination right in the prompt file’s header.

output_dir: ~/Documents/Obsidian/Vault/YouTube/レシピ
---
上の文字起こしをObsidianレシピ形式に変換して...

The output_dir: header sets the destination, and everything after the --- is the prompt body that gets passed to Claude. The target folder is created automatically if it doesn’t exist, and a -o flag lets you override it for a one-off run.

The overall structure

In the previous post this was a simple linear pipeline. With prompt switching and output routing added, it now looks like this.

Going fast by preferring subtitles

Once I generalized it, I tried it on a lecture video and hit a wall. Whisper transcription was way too slow — over 10 minutes for a 20-minute video. That was borderline tolerable for 5-10 minute cooking videos, but useless for an hour-long lecture.

The fix was simple: fetch YouTube’s subtitles first. Most Japanese-language videos have either manual or auto-generated captions available. When subtitles exist, fetching them takes seconds, and Whisper barely gets invoked anymore.

I also switched the Whisper model from large-v3 to large-v3-turbo. In the previous post I wrote about upgrading from medium to large-v3 for accuracy, but large-v3 is slow. large-v3-turbo keeps nearly the same accuracy while running much faster. With subtitles now preferred, Whisper rarely even runs — but it’s still nice to have a fast fallback.

Trying it out for real

I tested it on three kinds of videos.

Tool walkthrough (obsidian-skills) — subtitles fetched, transcript done in seconds. Came out as a clean note with setup steps, usage, and tips clearly separated.

Workout video (ab superset routine) — subtitles fetched. Output was an exercise table plus form notes. It even picked up practical warnings like “never bend your knees — it kills the effectiveness.”

Lecture (Takafumi Horie’s 1-hour talk at Takushoku University) — subtitles fetched, transcription was fast, but structuring it via the Claude CLI took 2-3 minutes. Output was organized into an overview, key points, detailed notes, and quotes — a full hour-long talk cleanly organized. If it had started from a Whisper transcription instead, it would have taken over 30 minutes, so this is exactly the kind of long-form video where preferring subtitles pays off the most.

Looking back

What was a recipe-only script dumped in ~/scripts/ when I wrote the last post is now a published, general-purpose tool on GitHub. Review, tests, CI, renaming the command, building a prompt system, preferring subtitles, switching models — all of it happened through conversations with Claude Code.

The subtitle-first change in particular is something I never would have noticed without actually trying a lecture video. As long as I was only using it for cooking videos, Whisper’s speed was never a problem — it took broadening the use case to even see the bottleneck. “Generalize it, discover a new problem, solve that, and it gets even better” might be one of the most fun parts of building things.

youtube-to-obsidian — works on any Apple Silicon Mac with Claude Code installed. Add your own prompt and it’ll turn any video into an Obsidian note, so feel free to customize it for your own use case.

I Built a Pipeline That Turns 40 YouTube Cooking Videos into Obsidian Recipe Notes

Tue, 16 Jun 2026 18:30:00 +0900

My YouTube “watch and cook later” playlist had ballooned to 43 videos. I kept saving cooking videos and never actually using them — every time I stood in the kitchen I’d end up pulling out my phone and reopening YouTube, wondering “wait, how did that recipe go again?” I’ve lost count of how many times I’ve done that. I already manage my recipes in Obsidian, so if I could just convert the contents of these videos into Obsidian notes, the problem would go away. I gave it a shot with Cowork (the desktop version of Claude), and the process turned out to have more twists and turns than I expected — worth writing down.

First, I tried one video by hand

I started simple: I handed Cowork a video URL and asked it to “put this recipe into Obsidian.” It was a video of chef Masahiro Kasahara making homemade nametake (simmered mushrooms). Cowork can open YouTube through a Chrome extension, so it read the description, searched the web for supplementary details, and somehow managed to produce a recipe from that one video.

But this approach has a fatal flaw: the token cost per video is brutal. Browser operations, page fetches, web searches, text formatting — do that 43 times and you’ll hit the session limit with room to spare. I needed a different approach.

Transcribing locally with Whisper

The part burning through all those tokens is “understanding what’s in the video.” If I could handle that locally, all I’d need to hand Claude would be a short block of text.

I wasn’t sure my MacBook Neo (A18 Pro / 8GB) could handle it, but Whisper’s medium model (750MB) turned out to run comfortably. Thanks to Apple Silicon’s Neural Engine, a 12-minute video transcribes in one to three minutes.

I used two tools: yt-dlp (to pull just the audio from YouTube) and mlx-whisper (a Whisper implementation optimized for Apple Silicon).

The setup wasn’t exactly smooth, though. First, yt-dlp requires ffmpeg, so I installed that too. Then, trying to install mlx-whisper, I found pip was outdated and needed an upgrade first. On top of that, the system Python was 3.9, and mlx-whisper requires 3.10+. Installing Python 3.12 via Homebrew ran straight into PEP 668’s “externally-managed-environment” restriction. In the end, setting up a venv was what actually solved it.

brew install yt-dlp ffmpeg python@3.12
python3.12 -m venv ~/scripts/.venv
source ~/scripts/.venv/bin/activate
pip install mlx-whisper

As always, the time sink is the environment setup you have to get through before you even reach the actual task.

Hitting the wall of Cowork’s sandbox

At first I tried running both yt-dlp and Whisper inside Cowork’s Linux sandbox, but access to YouTube got blocked by the proxy. Apparently the sandbox isn’t allowed to freely reach external sites. So I ended up running the audio download and transcription locally on the Mac, and only passing the resulting text to Cowork.

I tried Ollama, then gave up on it

I wanted to keep the conversion from transcript to recipe format local too, so I tried running gemma3:4b through Ollama. It technically worked, but the accuracy of pulling ingredients and steps out of a cooking transcript wasn’t great — especially around catching spoken quantities and separating actual recipe content from small talk.

In the end, I settled on a division of labor: local Whisper for the heavy lifting (transcription), and Claude for the intelligent part (formatting into a recipe). Leave it to the specialists.

Turning it into a Cowork skill

Cowork has a mechanism called “skills.” You write out how to do a task in Markdown, and from then on you just say something like “turn this into a recipe” and it follows that skill.

The skill I built here is simple: it reads the transcript text sitting in _transcripts/, converts it to match the format of my existing recipes (frontmatter + ingredient list + steps), and saves it into the Obsidian folder. The skill also has real examples of existing recipes embedded in it, which keeps the output format consistent.

Fully automating it with the Claude CLI

The last piece was the Claude Code CLI. Since you can pass it a prompt from the terminal with claude -p, I chained the whole thing together in a shell script:

#!/bin/bash
URL="${1:-https://www.youtube.com/playlist?list=PLh4huXs8Qi9HkMIXptPbw2gIYUDNtqNic}"

# Step 1: Transcribe locally (progress is visible)
"$HOME/scripts/.venv/bin/python3" ~/scripts/transcribe.py "$URL"
if [ $? -ne 0 ]; then
 echo "Transcription failed. Aborting."
 exit 1
fi

# Step 2: Turn it into recipes with the Claude CLI
claude -p "Convert the .txt files in _transcripts into Obsidian recipe format and save them"

In Step 1, Whisper’s progress shows up as [1/43], [2/43], and so on, and in Step 2 the Claude CLI batch-converts everything into recipes. If transcription fails across the board, it aborts before reaching Step 2. Early on I hit a trap where the Claude CLI would still run even after an error, burning API costs for nothing. Now a single run of ~/scripts/recipe turns the entire playlist into Obsidian recipe notes.

The final architecture

The heavy lifting (audio to text) runs on the Mac’s Neural Engine, and the intelligent work (text to structured recipe) runs on Claude — each handling what it’s best at.

Takeaways

What started as a simple wish — “I want to get YouTube recipes into Obsidian” — turned out to run into a string of obstacles once I actually tried it: Cowork’s sandbox has network restrictions, YouTube’s caption API isn’t straightforward to pull from, and local LLM accuracy falls short depending on the task. On top of that, I stepped on all the usual environment-setup landmines, like Python version conflicts and needing a venv. In the end, I landed on a combination of local Whisper plus the Claude CLI.

What’s interesting is that this whole process of trial and error unfolded as a conversation with Cowork. Whenever an error came up, I’d paste the terminal output, Cowork would suggest the next move, and I’d try again. As a debugging pair-programming partner, it was genuinely solid. Now that the 43-video playlist is sorted, maybe I’ll end up cooking more. Or maybe I won’t.

Life Update

Mon, 15 Jun 2026 21:30:56 +0900

Now that the blog is finally back from the dead, I figured I’d write a life update while I’m at it. Covering eight years in one post is a bit much, so here are a few of the bigger things that happened, roughly in order.

I changed jobs twice more

Since my last post, I’ve changed jobs two more times. Just counting the number might make me look fickle, but the criteria I use to pick a company have stayed consistent the whole time. One is: “how much benefit can this company realistically bring to Japan as a country?” The other is: “can I genuinely get behind what this company is trying to do, as if it were my own cause?” I’ve only moved when I could nod confidently on both counts. The jobs kept changing, but the yardstick never did.

I sold the Porsche

I let go of the 996 Carrera 4S I mentioned buying “on a whim” back then. It wasn’t that I wanted to sell it — there were circumstances involved that I’ll leave out here. It wasn’t what I wanted. The one silver lining is that it sold for more than I paid. Classic car prices have been climbing, so between all the fun I had owning it and coming out ahead financially, it wasn’t a total loss. Still, letting go of a car I loved, and not by choice, left a certain emptiness.

Syrup passed away

Our Maine Coon, Syrup, passed away too. I’m leaving here, unedited, what I wrote on Facebook the day it happened.

Our Maine Coon Syrup passed away today. He was 10 years old. In May, his left front leg suddenly became paralyzed, and even after tests at the vet, we couldn’t pin down the cause. The paralysis gradually spread until his whole body except his head and neck was affected, and he became bedridden.

His vet referred us to a large university animal hospital, where he was examined two weeks ago. General anesthesia was too risky, so he had an MRI and CT scan without it. But without a spinal fluid sample, a definitive diagnosis wasn’t possible — the two leading suspects were lymphoma or meningitis — so we continued with medication in the meantime.

Today we brought him back to the university hospital for a follow-up. They ran blood tests again and scheduled a spinal fluid draw under general anesthesia for two weeks out, and we headed home.

When I got him out of the car and opened his carrier, he had already stopped breathing. I called our regular vet and rushed him in, but he couldn’t be revived. The vet thought he’d likely had a seizure in the car and choked on blood-tinged sputum.

He used to weigh over 9kg, but once the paralysis set in he lost 3kg. If there’s such a thing as an afterlife, I hope he’s eating his fill — he always did love his food.

Syrup, I’m sorry I couldn’t save you. Thank you for everything.

I got a home battery, essentially for free

After something that heavy, let me throw in something more mundane. We installed a solar battery storage system at home. Tokyo’s subsidy for it turned out to be generous enough that we got it installed at essentially no cost. It helps with electricity bills and gives us a safety net in a disaster, and with a subsidy that good, there was no reason not to. Things like this are best taken advantage of while they last.

A trip to Sapporo for my nephew’s wedding

I went to Sapporo for my nephew’s wedding. It had been a while since I’d been there, and a while since the whole family had gotten together. Celebrations like that are always good to be at. Seeing the nephew who used to be so small standing up front in a suit made me feel my own age.

My mother moved into a care facility

My mother has dementia and is certified as needing long-term care. Her memories from long ago are mostly intact, but she can barely hold onto short-term memory — she won’t remember a conversation from a few minutes earlier. There were even times she looked at her own eldest daughter and didn’t know who she was. Until recently, my father had been taking care of her almost entirely on his own, handling every aspect of it.

Then my father was hospitalized, and with no one left to look after her, we had no choice but to move her into a care facility. That’s when it really hit me just how much my father had been doing, day in and day out. That level of devotion — there’s really no other word for it than remarkable.

My father passed away

And then my father passed away. I attended the wake and the funeral, and for the first time in my life went through the process of carrying out someone’s will.

My father had carefully set aside enough money to make sure my mother’s care would be well provided for after he was gone. He’d thought ahead and made the arrangements — genuinely something to respect.

My older brother handled all the funeral procedures and logistics. Standing next to him, all I could feel was my own uselessness. At the same time, watching him calmly shoulder everything made me realize he’s remarkable too. You don’t usually notice it day to day, but moments like this are when a person’s true measure shows.

The 49-day memorial has passed, and recently we divided up his belongings. I took his coat, his belt, and a cut-glass tumbler. I imagine I’ll think of him every time I pour a drink into that glass. That feels about right.

So, that’s about it

Writing it all out like this, I realize the past few years brought a lot at once — good and bad alike. I changed jobs, let go of a car I’d driven for years, said goodbye to a cat and to my father, and my mother moved into a care facility. Some things I gained, and some things I’ll never get back.

Even so, life goes on, and I’m doing okay. Managing to restart a blog I’d left untouched for eight years feels like a kind of turning point in itself. Next time, I’d like to write about something lighter — and hopefully a bit more often.

I Let Claude Casually Fix My Blog After 8 Years of Neglect

Fri, 12 Jun 2026 00:13:37 +0900

Turns out my last update was back in 2018. Eight years. I’d left it sitting there for eight years. When I finally opened my own blog again, it wasn’t even rendering properly anymore. The build was permanently broken, every photo in every post was gone, and the code blocks were a mess. I thought this was my castle. Turned out it was a ruin.

I couldn’t just leave it like that, so I threw a lazy request at Claude Code: “CircleCI’s failing, can you fix it with GitHub Actions?” It ended up doing about three times more than I expected, so I’m writing it down.

The build wasn’t even passing

Claude looked into it and found that CircleCI had already been migrated to GitHub Actions long ago — except that Actions setup was broken too. I don’t even remember doing the migration. The Hugo version was pinned to 0.74. Zero point seventy-four. From 2020. There was no way the current theme would work with that. On top of that, the submodule URL was pointing at git@github.com over SSH, so CI couldn’t fetch it without a key.

Claude tracked down all of this on its own, bumped Hugo, switched the submodule to HTTPS, and got everything building and deploying again like it was nothing. And all I’d said was “CircleCI’s failing.”

Every photo had vanished

Once the build was passing, the next problem showed up: not a single photo appeared in any post. There were two causes. First, Hugo’s Markdown engine had been updated, and it now strips raw HTML written directly in the body by default for safety — and past-me had hardcoded <img> tags everywhere. Second, the images were referenced over http://, which gets blocked as mixed content on an HTTPS site.

I hadn’t asked it to fix posts one by one, either. It went and found every affected post on its own (apparently around 60 of them), switched both the Flickr and Amazon product images over to HTTPS, and brought them all back in one pass. For the Amazon ad widgets that had long since been discontinued, it swapped them out for links to product pages that were actually still alive. A small thing, but I appreciated it.

The WordPress-era debt kept surfacing

The deeper it dug, the more of my own past sins turned up. Code blocks that opened with [sourcecode] and closed with ``` , breaking the rendering entirely (leftover WordPress shortcodes). Headings written as raw <h2> instead of Markdown. The best one: roughly 350 old daily-roundup posts from delicious — the social bookmarking service (younger readers may not know it, and it’s long gone now) — all still sitting there full of dead links. I really had let that pile up. Claude cleaned all of it up too, without a word of complaint.

And then it modernized things while it was at it

What started as just a fix turned into a bunch of extras along the way: prev/next navigation between posts, switching the homepage from full-text posts to summaries with a “read more” link, site search (just redirects to Google’s site: search — no index or server needed), a monthly archive sidebar, an RSS icon. It even fixed the sitemap to use absolute URLs so Search Console would stop complaining. It’s clearly a lot faster at this than I was eight years ago.

The part that impressed me most

Once everything was done, I asked it to “check with me before pushing straight to master,” and it went and wrote a hook to enforce that. From now on it actually stops and asks before pushing. It’s a little unsettling how it doesn’t just do what you ask — it goes and reshapes the whole environment to match how you work.

Eight years of neglect and the scars of a WordPress migration, cleared up almost entirely through casual chat. I’ll admit it: I didn’t fix a single line of code myself in this whole process. All I did was sit there typing “fix this” and “now this” in chat. If I’d done it all myself, I think I’d have lost three weekends to it.

…and if you’ve read this far, you might have already guessed — yeah, this post’s draft was written by Claude too (lol).

Six months after I impulse-bought a Porsche 911

Sun, 03 Jun 2018 00:40:00 +0900

What I bought

A Porsche 911 Type 996 Carrera 4S, late model, registered in ‘04, fitted with a high-performance kit. Stock output is 320 ps, but the kit bumps it up to 345 ps.

Drivetrain: AWD
Engine: 3.6L flat-six, DOHC, 6-speed manual
Max output: 345 ps @ 6800 rpm
Max torque: 37.7 kgm @ 4750 rpm
Length x width x height: 4435 x 1830 x 1295 mm
Wheelbase: 2350 mm
Curb weight: 1520 kg

It’s naturally aspirated, but as a 4S it gets the same wide body, stronger brakes, and retuned suspension as the turbo model. The AWD system uses a multi-plate viscous coupling that shifts torque to the front axle anywhere from 5% up to 40%.

The previous owner made a few modifications: a GT3-ish aero kit (with a fixed rear wing) and headlights swapped to the 997 look. The suspension and intake/exhaust appear to be stock. The alloy wheels are aftermarket BBS, with different part numbers front and rear. The intermediate shaft had already been replaced with the reinforced version.

Can an ordinary person actually afford a 911?

The first thing I want to stress is that a 911 is surprisingly attainable. Ferraris and Lamborghinis are basically out of reach for regular people no matter how hard you dig through the used market. Porsche, though, is actually within striking distance. Air-cooled models have gotten pricey for historical reasons, but if you’re fine with water-cooled, the 996 and 997 sit at prices most people could realistically manage — not much different from buying a new mid-range Japanese car. The exceptions are the halo models like the GT2 and GT3 — forget those — and turbo models, which cost more than the NA versions.

The 996 was Porsche’s first water-cooled model, infamous for swapping the classic “frog eye” headlights for the teardrop lights it shared with the Boxster, which drew plenty of criticism at the time. It launched in ‘97, so it’s already a 21-year-old car and arguably a classic at this point, yet its resale value is still holding up remarkably well. There’s a wide range within the 911 lineup, but a basic Carrera with 60,000-100,000 km on the clock can be had for roughly 2.5-4 million yen. Move up to a 997 and the average price jumps noticeably, so I’d argue the late-model 3.6L 996 is currently the sweet spot for value.

Maintenance and running costs

People often say Porsches are expensive to maintain, but honestly they’re built pretty tough. If you keep up with preventive maintenance, I don’t think you end up with the absurd bills people imagine. That said, engine oil is one area where you really do need to stay on top of things and use good oil.

Specifically, the approved oil is Mobil 1 5W-40. A 4-liter jug runs about 4,000-5,000 yen, and an oil change uses roughly 9 liters, so even doing it yourself you’re looking at that kind of cost each time. Running costs are definitely higher than a typical Japanese car, so budget for that. Still, it’s nothing like a Ferrari or Lamborghini where every little thing costs hundreds of thousands of yen. Fuel economy is, unsurprisingly, not great. It improves with each generation — 996 to 997 to 991 to 992 — but for a 996 this old, figure on roughly 5-8 km/L. Oil management deserves more attention here than on an ordinary car, though it’s far better in this regard than the air-cooled models. Also, since it uses a semi-dry-sump system, I’d avoid getting the oil changed at chain stores like Autobacs or a regular gas station.

Genuine parts are also pretty pricey — understandable given the quality, since the stock dampers are Bilstein and the brakes are Brembo. Porsche Center labor rates are steep too. If you’re thinking about buying one, I’d recommend scouting out a reputable independent shop nearby ahead of time — ideally one equipped with a proper Porsche diagnostic tester.

Another mildly annoying point: you can’t buy tires and wheels as a matching set of four, because the front and rear sizes are completely different. Stock is 225/40ZR18 up front and 295/30ZR18 in the rear. The rear tires in particular aren’t cheap at that size, so brace yourself.

Interior

Honestly, it’s a bit underwhelming. For a car with an MSRP north of 10 million yen, you’d hope for more — but then again, it’s a 20-year-old car. The newer 992 has a genuinely great interior, though of course its sticker price is roughly double. The Alcantara headliner and the powered leather seats are nice touches, at least.

Ride quality

The suspension is noticeably stiffer than a typical car. The rear +2 seats are barely more than a token gesture — not a space any adult man would want to sit in for long. Someone around 150 cm tall could probably manage back there. Being a 3.6L NA engine, torque is strong even at low revs — strong enough that you can pull away in second gear from idle without touching the throttle. It has six gears, but they’re tightly stacked; even in sixth, cruising at 100 km/h sits around 2000 rpm. The dampers are probably a bit worn from age, so you feel bumps and manhole covers, but nothing jarring enough to complain about.

The smooth rev build you only get from a naturally aspirated engine, the ample torque of the 3.6L, that distinctive flat-six growl coming from behind you, the glued-to-the-road stability from AWD, the reassurance of a rear engine helping braking performance — all of it adds up to a daily-driving experience that keeps reminding you “Porsche really knows how to build a car.”

The throttle response is so sharp that if you pull away from a stop the way you would in a normal car, the engine revs way more than you expect and it’s hard to move off smoothly. You can actually pull away on clutch alone without touching the accelerator at all, which might even be gentler on the clutch. As long as you’re not on a hill, starting in third gear is entirely doable.

Left-hand drive

Porsche does offer right-hand-drive versions, and honestly I think that’s the better choice. This is my first time driving a left-hand-drive car, and in Japan the downsides overwhelmingly outweigh the upsides. Right turns at intersections are the biggest problem. If there’s oncoming traffic waiting to turn right, it’s genuinely hard to see straight-through traffic coming up behind them — you end up leaning toward the passenger seat and craning as far right as you can. Passing a bus is also tricky. On a single-lane residential street, if the bus ahead of you stops at a bus stop and you try to pass normally, a left-hand-drive car puts you at real risk, because the bus blocks your view of oncoming traffic completely. By the time you’ve eased over far enough to see, you’re already well into the oncoming lane. Your only real options are to leave a generous following distance behind buses, or just resign yourself to stopping behind them at bus stops.

The upsides of left-hand drive are that you basically never risk clipping a pedestrian on a left turn, and it’s easier to hug the left edge to the limit when passing on a very narrow road. That said, since your view to the right is limited, it’s safer to stop once you’ve pulled left and let oncoming traffic — who can see you more easily — pass first. Two left-hand-drive cars meeting on a narrow road, though… that’s rough (laughs). It’s also easier to spot pedestrians walking on the left, especially at night.

That said, since the car was originally designed around left-hand drive, converting it to right-hand drive introduces a few quirks — this isn’t unique to Porsche. The pedal placement ends up slightly and unnaturally shifted toward the center of the car, and the throttle cable has to run longer than it would on a factory left-hand-drive car, which can make it feel a bit awkward and wear out faster. Neither of these can really be avoided — it’s just physics.

The body is wider in the back than the front

This takes real getting used to. On most cars, the front track and rear track are basically the same width. But because the 911 is rear-engine, rear-drive, the rear is wider than the front. The practical effect is that parking the car straight is genuinely harder than you’d expect, and it gets even trickier in reverse. It takes a fair amount of practice to develop a feel for which reference point on the car lines up straight. Visibility over your right shoulder is essentially nonexistent, so backing into a spot on your right as you approach requires real care.

Wrap-up

I’ve written a lot here, but this car has enough fun packed into it to offset the downsides. It’s the kind of car that gets filed under “dream car,” and the sharp responsiveness and solid, honest build quality tug at something in the male psyche. Unlike a lot of so-called supercars, it’s not a pain to drive around town, and on top of that, the used prices are genuinely reasonable. Its resale value also holds up far better than most other cars. It’s not going to appreciate above its original price like a Ferrari can (special models like the GT3 aside), but compared to an ordinary car, “dramatically” better resale is a fair way to put it.

The 997 still feels a bit pricey right now, so going with a 996 isn’t a bad call at all. That said, 997 prices are gradually starting to come down too, so if you’re buying, timing is worth thinking carefully about. The newer the model year, the smaller the pool of manual-transmission cars on the used market, so if you specifically want a manual, you may need to search patiently. Ordering a complete build from a shop isn’t a bad option either, come to think of it. If you go with a 996, definitely go for the late model. The early model has a removable cup holder (the late model’s retracts), and it also lacks a glovebox. On top of that, the late model comes standard with PSM (Porsche Stability Management).

After two years I finally felt like updating my blog, so I sorted through my photos and posted them

Sat, 02 Jun 2018 13:56:54 +0900

My photo backlog has gotten completely out of hand

I’d left this blog untouched for two years, and in that time an insane number of unpublished photos piled up. I hadn’t even developed most of them, so I spent a weekend wrestling with Lightroom, blasted through a batch of edits, and now I’m posting them all at once.

Tokyo Motor Show 2017

This is from last year’s motor show. I didn’t take a single photo of the booth companions — I basically went just to see the AMG Project ONE. We also got to sit in a lot of the driver’s seats, so my wife happily hopped into one sports car after another.

Sapporo Snow Festival 2018

The Sapporo Snow Festival — famous for the fact that actual Sapporo residents never bother going. Still, this was only my second time attending since I moved away from the city. This time I brought my wife along. Our whole goal was the giant FF14 snow sculpture of Estinien and Nidhogg — honestly that’s the only sculpture we even looked at (lol).

Ashikaga Flower Park

My wife had been saying for ages she wanted to see the giant wisteria trellis at Ashikaga Flower Park, so we finally went. It had been an unusually warm year and the wisteria looked set to bloom early, so we took time off ahead of Golden Week to beat the crowds. That turned out to be exactly the right call — the wisteria was in full, glorious bloom. If we’d waited until the second half of Golden Week, I suspect it would already have been past its peak. It’s a bit of a trek out there, but it was far more satisfying than I expected.

Sumida Aquarium

Went with my wife and one of her friends. This also happened to be my first time near Tokyo Skytree. I figured the Skytree’s own parking lot would be impossibly crowded, so I parked at the Ito-Yokado in Hikifune and took the train one stop instead — and that bet paid off. Where I miscalculated was the food: every restaurant nearby was packed solid, and we ended up waiting 30 minutes just to buy tickets. It’s a small aquarium so you can get through it quickly, but if I had to pick highlights, it’d be the garden eels, the giant isopod, and the penguins.

Tokyo Racecourse — NHK Mile Cup

Through a rather unexpected connection, I ended up invited to the owners’ seating and watched the race from there. We even got access to the underground passage by the weighing room and the paddock. Aside from not actually winning any money, it was fantastic. Here’s what comes with an owner’s seat:

A reserved, covered seat right along the home stretch
A monitor, drink holder, betting-slip holder, and space for your bags, all at your seat
Dedicated betting windows, smoking area, snack counter, and restaurant just for owners’ seating
Access down to paddock level, right up close to the horses

To get inside the paddock itself, though, you apparently need an invitation from an owner who actually has a horse running that day — those people are the ones wearing ribbons on their clothes.

Kawasaki Factory Night View

On a sudden whim, I headed out to the Ogimachi area of Kawasaki to shoot the factory night views. I forgot my tripod, so everything’s handheld. I never quite found the composition I was picturing — maybe it would’ve been better if I’d walked up onto the bridge? Regardless, the drive along the Tama River toward Gasu Bridge near Futako-Tamagawa felt fantastic. I’d love to go back.

Jindai Botanical Gardens

Another spot my wife had been wanting to visit. Given the season, roses were clearly the main event, so that’s what we focused on. The gardens are bigger than I expected, so covering the whole place takes a fair bit of time. The parking lot is also seriously crowded, so you’ll likely get redirected to the overflow lot and have to walk a bit — wear shoes you can actually walk in.

A solo trip to Itsukushima Shrine, Ise Grand Shrine, and Kyoto

Thu, 05 May 2016 13:56:54 +0900

A solo trip to Itsukushima Shrine, Ise Grand Shrine, and Kyoto

TL;DR

A record of a solo trip I took from 2016/05/01 to 2016/05/04, three nights and four days, leaving my wife behind to work while I wandered off on my own. There’s no real point to it. Just a bunch of photos below.

Hiroshima - Itsukushima Shrine

On the 1st I took the Shinkansen from Tokyo to Hiroshima. Since I’d be staying at @WINGS1685’s place in Kyoto, I wanted to bring a souvenir, so I arrived at Tokyo Station about two hours before departure to buy the requested Toshimaya Kizahashi… or so I’d planned. I’d gotten the Shinkansen time wrong and couldn’t buy it. I’d originally booked the 13:00 departure, but since the night cruise to visit Miyajima at my hotel required dinner starting at 17:00, I’d changed it to 11:00 so I’d arrive around 16:00 — and then completely forgot I’d done that. So off to Hiroshima I went, empty-handed, getting an earful over chat the whole way.

I stayed at the Aki Grand Hotel. Unfortunately only mountain-view rooms were left, but I could at least catch a glimpse of the sea from near the emergency exit.

The view from my room

The view from the 9th-floor emergency exit

The lobby

Stepping out onto the terrace from the lobby

Since the night cruise was coming up, I had an early dinner. The hotel has a few different dining options, and this time I went for a course meal at a place with an izakaya-ish vibe.

After a leisurely meal, I took a relaxed bath while waiting for the cruise. Sadly it’s not a hot spring, and the open-air bath was reservation-only anyway. Also, there were a lot of foreign tourists around, and their bathhouse etiquette left something to be desired. I get that a UNESCO World Heritage site draws a lot of travelers, so it’s somewhat unavoidable, but I do wish people would follow at least some of the local customs. Wearing swimwear in the sauna, taking photos in the bath area — that’s just not okay.

Anyway, setting that aside, I stepped out onto the terrace before the night cruise. The city lights were sparse.

And then, the night cruise. Basically a sightseeing boat, capacity maybe 20 people. We listened to the guide’s commentary, and once we got close, everyone stepped out on deck to pay respects before the photo session began.

It was interesting how much the mood changes depending on the tide. Speaking of Itsukushima Shrine, it’s one of Japan’s three most scenic views, alongside:

Matsushima in Miyagi
Amanohashidate in Kyoto
Miyajima

Our guide told us all sorts of things: that the area used to be forbidden ground, that the torii gate isn’t buried in the seabed but simply stands under its own weight on a foundation of thousand-pillar piles, that the current gate is the 8th reconstruction, built in the Meiji era, and that the plaque bears different characters on the ocean side versus the shrine side. Being one of Japan’s three great torii gates, its silhouette really is mystical.

The next day, I took the ferry over to Miyajima.

From the ferry, a mountain that looks like a reclining Kannon

I wandered around Miyajima in the morning, then took the ferry to the Peace Memorial Park museum and the Atomic Bomb Dome in the afternoon. Since I’d failed to buy the kizahashi, I’d been given a divine decree that a butter cake from a place called Nagasakido would earn my forgiveness, so I went to buy one — only to find it was already sold out and closed by 13:00…

About half the visitors at the museum were foreign tourists, which really shows how much interest there is worldwide. The volunteer guide, an older gentleman, spoke fluent English and explained the circumstances at the moment the bomb went off. Seeing personal belongings with people’s names still on them, a model showing the size of the fireball at detonation, a full-scale replica of the bomb itself — it was all so visceral it left me at a loss for words. If you ever have the chance to go, I’d recommend setting aside an hour or so to look through the museum carefully and really reflect. It’s not a place you want to rush through.

Kyoto - Ise Grand Shrine

In the evening I took the Shinkansen from Hiroshima to Kyoto. I had oyakodon near Shijo-Omiya, stayed the night, then headed to Mie the next morning. My host had gotten hold of an Ise Grand Shrine visitor’s pass — a great deal that covered a round trip from Kyoto to Ise Grand Shrine for 6,600 yen, two Kintetsu limited express rides between Matsusaka and Kashikojima, and unlimited rides on Mie Kotsu buses in the Ise area. Making full use of it, before visiting the outer shrine I got off at Ise-shi Station, headed to Futaminoura Station, and went to Futami Okitama Shrine, home of the famous Wedded Rocks.

Despite it being Golden Week, there was almost no one around the station, which was a little unsettling. On top of that, with the Ise-Shima Summit coming up soon, police had gathered from Mie and neighboring areas alike — intimidating-looking transport vehicles were parked everywhere, and I saw plenty of officers who looked like they were in training. If it’s already like this a month out, I can only imagine how tense things will get closer to the date. Once I actually reached my destination, though, there were a fair number of people. I guess most people get there by car — the trains only run twice an hour, after all…

I grabbed a meal near the station at a place called Ogiya before heading to Ise Grand Shrine. I’d picked Ogiya completely at random, but it turned out to be a great find — both the Matsusaka beef hamburger steak and the fried Ise lobster were delicious.

I took the bus from the outer shrine to the inner shrine. Between the stop at the Wedded Rocks and trying to visit more than just the main sanctuary, time got pretty tight. I kept the souvenir shopping brief and headed back. I’d braced myself for Golden Week crowds, but it wasn’t unbearably packed, and I got to fully enjoy my first visit to Ise. What struck me was that every main hall has an empty plot right next to it, reserved for the next Shikinen Sengu rebuilding — the sheer effort of rebuilding everything, including all the auxiliary shrines, is staggering. While I was paying my respects at the inner shrine, I overheard what sounded like part-time staff collecting the offering money saying things like “how many bags today, seven?” — a bit too candid for comfort. I thought, maybe have that conversation somewhere tourists can’t hear you.

Back in Kyoto, I had delicious salt ramen at a place with the silly name Pakopako. The broth had that “clearly took real effort” kind of depth to it.

Kyoto - Kaiko-no-Yashiro and the Tenji Tenno Mausoleum

Kyoto during Golden Week is packed, but I got dragged along, sight unseen, to some spots that were supposedly uncrowded and lovely. First up was Kaiko-no-Yashiro, formally Konoshima-ni-Masu-Amaterumitama Shrine. Remarkably quiet, and home to an extremely rare triple torii gate. The spot where the triple torii stands used to be a pond called the Mototadasu Pond, apparently, though sadly it’s dried up now. No one really knows for certain why this gate was built. Mysterious stuff.

From there we took the train to Okakita, an udon place in Higashiyama. We lined up for about an hour and a half starting at 11:00, finally getting inside around 12:30. The tempura udon, topped with fluffy egg, had a broth with a clean, well-balanced dashi flavor — excellent. My craving for meat wouldn’t quit, so I also ordered the mini beef bowl, seasoned like a sweet sukiyaki. Since it was also finished with egg, it stayed piping hot the whole time. Combined with the nice weather, the heat was honestly a lot to handle. I can’t imagine eating this in the height of summer. But it was delicious. Incidentally, the udon shop right next door had just as long a line.

With lunch taken care of, we took the train to the Tenji Tenno Mausoleum, also known as Gobyono Kofun. Also almost completely deserted, but with a different, equally mysterious atmosphere from the shrines.

Wrap-up

Huge thanks to @WINGS1685 and their spouse for putting together such a great itinerary on short notice and letting me stay two nights. Next time I’ll make sure I actually manage to buy the souvenirs, lol. Though the raw momiji manju ended up being more of a hit than expected, so it worked out fine. I never made it to Hiroshima Castle, never saw Itsukushima Shrine at high tide, never climbed the mountain on Miyajima, and never got in the hot spring — so I’m definitely due for a rematch. As for Ise Grand Shrine, I’d love to bring my wife next time. It’d be nice if it were a bit easier to get to from Tokyo. I keep ending up in Kyoto in May specifically, and while part of me wants to see it in a different season, it’s either too hot, too cold, or too crowded depending on when I go. Still, I really do want to catch the autumn leaves at some point…