DEV Community: Rick Cogley

Engineering Backpressure: Keeping AI-Generated Code Honest Across 10 SvelteKit Repos

Rick Cogley — Fri, 03 Apr 2026 12:28:24 +0000

I manage about ten SvelteKit repositories deployed on Cloudflare Workers, and leveraged Anthropic's Claude Code to do it. Generally speaking, AI coding assistance can be fast and capable, especially if you already know how to code, but precisely because they are so fast, they can be — if you're not careful — consistently wrong in ways that are hard to spot.

Not wrong as in "the code doesn't work." Wrong as in: it uses .parse() instead of .safeParse(), it interpolates variables into D1 SQL strings instead of using .bind(), it fires off database mutations without checking the result, it nests four levels of async logic inside a load function that should have been split into helpers. The code works. It passes TypeScript.

The problem is that if you add guidance to your CLAUDE.md file (or other coding agents' guide files) such as "always use safeParse()" and "never interpolate SQL", those are just suggestions, not constraints. The AI reads them, and might follow them, but also it might not. There is no compiler error when it forgets. The instruction is non-deterministic, so the compliance is non-deterministic too.

This post is about how I made compliance deterministic.

The Principle

In hydraulics, 'backpressure' is resistance applied to a flow to regulate it. In software, the equivalent is making bad patterns structurally impossible rather than merely discouraged.

A CLAUDE.md instruction is a sign on the pipe that says "please don't overflow." A lint rule is a pressure valve that rejects the bad flow automatically. The sign might be ignored; the valve cannot.

The goal: migrate every "always" and "never" statement out of documentation into something mechanical — a type, a lint rule, a test, or a structural check. What remains in CLAUDE.md should be context and intent — the why, not the what.

Three Linting Passes

Each linting tool has a different strength.

oxlint (~50ms) — Rust-based, checks ~200 universal JS/TS rules. Fast correctness pass.

ESLint + Svelte plugin — Understands .svelte files as a whole. Hosts custom backpressure rules:

Rule	What it catches
`no-raw-html`	`{@html expr}` without sanitization
`no-binding-leak`	Returning `platform.env.*` from load functions
`no-schema-parse`	`.parse()` instead of `.safeParse()` on Zod
`no-silent-catch`	Empty catch blocks

These encode exactly the "always" and "never" statements that used to live only in prose.

ast-grep — The newest and most interesting. Uses tree-sitter to match code by structure. Rules are declarative YAML:

id: n-plus-one-query-map
language: TypeScript
severity: warning
message: >-
  Potential N+1 query: database call inside .map().
  Use db.batch() or WHERE IN instead.
rule:
  pattern: $ARR.map($$$ARGS)
  has:
    pattern: $DB.prepare($$$SQL)
    stopBy: end

This catches something neither oxlint nor ESLint can express: a database query nested inside an array iteration. In a SvelteKit load function hitting Cloudflare D1, this is a performance disaster. The AI generates this regularly because it looks correct and works fine on small datasets.

Full ast-grep rule set:

Rule	What it catches
`sql-injection-d1`	Template literals in `db.prepare()`
`n-plus-one-query-*`	DB calls inside `.map()`, `.forEach()`, `for...of`
`unbounded-query-all`	`.all()` without LIMIT
`unchecked-db-run`	Fire-and-forget `.run()`
`empty-catch-block`	Silent error swallowing

Each corresponds to a mistake I found in AI-generated code that passed both oxlint and ESLint.

Tracking Upstream

Mechanical enforcement handles known patterns. But Svelte and Cloudflare ship constantly — SvelteKit has had 50+ releases since 5.0. The AI doesn't know about features released last week.

I built a "what's new" audit: a shell script fetches my SvelteKit patterns feed (a JSON Feed 1.1 endpoint with grep-friendly search signatures) and the Cloudflare changelog RSS. It filters CF entries to only the products each repo uses (by reading wrangler.jsonc bindings), then searches source code for legacy patterns.

Output: "repo x has 3 files still using writable() stores — $state class replacement available since Svelte 5.29."

When the audit discovers features not in the feed, it flags those as gaps. The feed stays current because the audit tells us when it's behind. The audit runs in about 10 seconds across all ten repos — it's a shell script, not an AI call.

Centralize, Then Distribute

All rules, configs, and workflows live in one .github repo. A sync script distributes to ten consumer repos. One sync-all.sh updates everything. No drift.

What It Catches

Since deploying, the ast-grep rules alone have flagged:

Template literal SQL injection in load functions the AI generated when asked to "add a search filter"
N+1 patterns where the AI helpfully awaited each item individually
Unbounded .all() queries that worked in development (5 rows) and would have timed out in production (50,000 rows)
Empty catch blocks where D1 errors vanished silently

None produced TypeScript errors. None were caught by oxlint or ESLint. All would have shipped.

Takeaways

Audit your CLAUDE.md or other guidance files for "always" and "never" statements. Each is a candidate for a lint rule or type constraint. Do that, then remove the prose.
Linters have different strengths. oxlint (fast, shallow) + ESLint (framework-aware) + ast-grep (structural) at 50ms + 2s + 200ms is still faster than one human review.
Track upstream releases programmatically. A structured feed with search signatures turns "what's new?" into a deterministic scan.
Centralize, then distribute. Ten repos with synced configs means zero drift.

The AI writes code faster than you can review it. The answer isn't slower AI — it's making the codebase reject bad patterns automatically, immediately, and without judgment.

The systems described here are specific to SvelteKit on Cloudflare Workers, but the principle — mechanical enforcement over written instructions — applies to any AI-assisted codebase. My svelte patterns feed is public if you want to point your own tooling at it.

Originally published at cogley.jp

Rick Cogley is CEO of eSolia Inc., providing bilingual IT outsourcing and infrastructure services in Tokyo, Japan.

Learn the Hard Way First: Why New Developers Should Build Skills Before Leaning on AI

Rick Cogley — Sat, 28 Mar 2026 01:59:54 +0000

Welcome to your first job, freshers. You've probably already used ChatGPT or Copilot to get through assignments. I'm not here to tell you to avoid AI forever. But if you skip the struggle now, you'll pay for it for years.

Garbage In, Garbage Out

GIGO applies perfectly to AI-assisted development. The quality of your prompts depends entirely on what you already know. If you've never written a SQL query by hand, you won't notice when the generated one has a subtle N+1 problem. If you've never debugged a race condition, you won't even know to ask about concurrency.

The AI doesn't know what you don't know. It will confidently hand you something that looks right. Your job is to know enough to catch when it isn't.

The "It Works" Trap

New devs fall into a pattern: prompt → paste → it runs → ship. But "it works" is the lowest bar. Code that works can still be unmaintainable, insecure, brittle, or wildly inefficient.

As Edsger Dijkstra put it:

"Program testing can be a very effective way to show the presence of bugs, but it is hopelessly inadequate for showing their absence."

History is full of "working" code that caused disasters:

Ariane 5 (1996) — Code reused from Ariane 4 had a 64-bit to 16-bit cast that overflowed on the new rocket's trajectory. Both redundant nav units crashed (identical code). The rocket exploded 37 seconds after launch.
Knight Capital (2012) — A deploy missed 1 of 8 servers. Dead code from a deprecated feature got accidentally reactivated. $440 million lost in 45 minutes.
Therac-25 (1985–87) — A race condition delivered 100x radiation doses, killing three patients. Previous models had the same bug, but hardware interlocks caught it. When the hardware safety was removed and software was trusted alone, people died.

When the production incident hits at 2 AM, "the AI wrote it" isn't a debugging strategy.

What "The Hard Way" Means

Write it yourself first, then compare. In his 2016 TED talk, Linus Torvalds showed two C implementations for linked list removal — both produce identical output, but the elegant one eliminates a special case entirely. He called this "good taste":

"Sometimes you can see a problem in a different way and rewrite it so that a special case goes away and becomes the normal case. And that's good code."

You only develop that taste by writing the ugly version first.

Debug without AI. Brian Kernighan wrote:

"Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it?"

If AI writes at the limit of your understanding, you've guaranteed you can't debug it.

Understand the fundamentals. Data structures, HTTP, how databases work. These aren't academic exercises — they're the vocabulary for asking good questions.

Read other people's code. Pattern recognition compounds over your entire career. AI can't shortcut this for you.

Learn to test properly. Kent Beck's progression:

"Make it work, make it right, make it fast."

"Make it work" is step one of three — not the finish line.

A Practical Ramp

First 3 months: Minimize AI coding assistance. Write and debug by hand.
Months 4–6: Use AI for exploration — explaining concepts, showing tradeoffs. Teacher, not ghostwriter.
Months 6–12: Use AI for acceleration — boilerplate, test suggestions, design rubber-ducking.
Always: If AI generates code you don't understand, stop. Don't use it until you do.

The Multiplier Effect

AI multiplies whatever you give it. Deep understanding becomes extraordinary productivity. Bad assumptions become extraordinary damage. Knight Capital didn't lose $440 million from one mistake — they lost it because a chain of "it works" assumptions got multiplied faster than any human could intervene.

Build the foundation first. Learn the hard way. It's the fastest path to becoming the kind of developer who can actually wield AI effectively — rather than the kind who feeds it garbage and ships the output.

The full version of this article — with additional disaster case studies, quotes from Dijkstra, Hoare, Torvalds, Kernighan, and Fowler, and a section on Japan's April new-graduate season — is on cogley.jp.

Rick Cogley is CEO of eSolia Inc., providing bilingual IT outsourcing and infrastructure services in Tokyo, Japan.

Audit Your SvelteKit Codebase with a JSON Feed of 34 Svelte 5 Patterns

Rick Cogley — Thu, 26 Mar 2026 21:09:50 +0000

My Migrate to Svelte 5 site started as a side-by-side reference for developers wanting to convert to Svelte 5, from React, Vue, or Angular. It maps concepts across frameworks: "your useState is Svelte's $state," "your useEffect is $effect," and so on — about 300 entries covering syntax, architecture, and ecosystem.

That's useful, for a human reading the site. But I kept running into a different scenario: working in a SvelteKit codebase with Claude Code and wanting to ask "go check what's new in Svelte and see what applies here." Because that kind of quick synthesis is what AI Agents are good at. The data was all on the site, but there was no machine-friendly way to query it for actionable patterns.

So I added two things to the site: a structured patterns feed and a browsable patterns page. This post covers the thinking and the implementation.

The Problem with Static Migration Guides

A migration guide answers "how do I do X in Svelte?" That's a pull interaction — the developer has a question and looks up the answer. Useful, but limited to that style of questioning.

What I wanted was a push interaction: "here are the 34 things Svelte shipped since 5.0 that you should know about, with exact code patterns to search for in your repo." An AI coding assistant could fetch this, grep the codebase, and say "you're still using writable() stores in 12 files — here's the $state class replacement." A bit of a pain for a human dev, but short work for an AI.

The key insight: the migration guide already had the "from" and "to" for each pattern. It just needed to be structured as queryable data instead of prose.

Why a JSON Feed, Not a Custom Format

My first attempt was a /llms-whatsnew.txt endpoint with bespoke SEARCH FOR / REPLACE WITH sections. It worked, but it was a made-up format pretending to be part of a standard. The llms.txt convention defines only two files — llms.txt and llms-full.txt. Adding llms-whatsnew.txt was inventing a spec, and agents would not be able to figure that out unless you specify each time.

A JSON Feed 1.1 solved this properly:

It's a real spec with existing tooling (feed readers, aggregators, automation)
Extension fields (underscore-prefixed) carry custom data without breaking compatibility
Any tool that understands JSON Feed can consume it; the _svelte_pattern extensions are bonus data for tools that know about them
One endpoint serves feed readers, AI agents, and automation equally

The decision came from asking a simple question: if someone discovers this endpoint without documentation, can they use it? With JSON Feed, yes — any feed reader picks it up. With a custom .txt format, no, not really.

The Patterns Data Structure

Each pattern in patterns.ts represents one actionable Svelte feature:

interface SveltePattern {
  id: string;
  title: string;
  title_ja?: string;
  since: string; // "svelte@5.29.0" or "sveltekit@2.55.0"
  date_added: string;
  category: 'syntax' | 'architecture' | 'ecosystem' | 'tooling';
  frameworks: ('react' | 'vue' | 'angular' | 'svelte4' | 'all')[];
  summary: string;
  summary_ja?: string;
  search_signatures: string[]; // grep-friendly patterns
  replacement: string; // modern Svelte 5 code
  release_url: string; // GitHub release page
  docs: { label: string; url: string }[];
}

The search_signatures field is what makes this useful for automation. Each entry is a string you can literally grep for. An AI assistant reads these, runs them against your codebase, and finds where old patterns still live.

Here's what an attachments pattern looks like:

{
  id: 'attachments',
  title: 'Attachments Replace use: Actions',
  since: 'svelte@5.29.0',
  search_signatures: [
    'use:action', 'use:tooltip', 'use:clickOutside',
    "from 'svelte/action'", 'Action<'
  ],
  replacement: `{@attach (element) => {
  element.focus();
  return () => { /* cleanup */ };
}}`,
  release_url: 'https://github.com/sveltejs/svelte/releases/tag/svelte%405.29.0',
  docs: [{ label: 'Attachments', url: 'https://svelte.dev/docs/svelte/@attach' }],
}

The release_url links directly to the GitHub release page for the version that introduced this feature. Every pattern is traceable, then, to its exact release.

Two Feeds, Two Audiences

I ended up with two separate JSON Feed endpoints serving different purposes:

/feeds/changelog.json — what changed on the site itself, e.g. new mappings added, content updates, bug fixes. For subscribers who want to know when the reference itself is updated.

/feeds/patterns.json — the actionable patterns feed. Each item is a Svelte feature with search signatures, replacement code, and a link to the GitHub release. Supports filtering:

/feeds/patterns.json?since=5.54          # Svelte 5.54+ patterns only
/feeds/patterns.json?category=syntax     # Just syntax patterns
/feeds/patterns.json?framework=react     # Patterns relevant to React migrants
/feeds/patterns.json?lang=ja             # Japanese summaries

The separation here is important, because the audiences are different. Someone subscribing to the changelog wants to know "did this reference get updated?" Someone (or something) querying the patterns feed wants to know "what Svelte features should I adopt?"

The Feed Extension

JSON Feed 1.1 supports extension fields prefixed with an underscore. Standard feed readers ignore them; tools that understand the schema use them. The _svelte_pattern extension carries the structured data:

{
  "version": "https://jsonfeed.org/version/1.1",
  "title": "Svelte 5 Migration Patterns",
  "_svelte_patterns_meta": {
    "total_patterns": 34,
    "filtered_patterns": 34,
    "usage_hint": "Each item._svelte_pattern.search_signatures contains grep-friendly strings..."
  },
  "items": [
    {
      "id": "https://svelte.cogley.jp/patterns/attachments",
      "title": "Attachments Replace use: Actions",
      "date_published": "2026-03-08T00:00:00Z",
      "tags": ["syntax", "all"],
      "_svelte_pattern": {
        "id": "attachments",
        "since": "svelte@5.29.0",
        "category": "syntax",
        "frameworks": ["all"],
        "search_signatures": ["use:action", "use:tooltip", "use:clickOutside"],
        "replacement": "{@attach (element) => { ... }}",
        "notes": "use: still works but is legacy. Attachments work on components too.",
        "release_url": "https://github.com/sveltejs/svelte/releases/tag/svelte%405.29.0",
        "docs": [{ "label": "Attachments", "url": "https://svelte.dev/docs/svelte/@attach" }]
      }
    }
  ]
}

The _svelte_patterns_meta at the feed level includes a usage_hint that tells any AI agent reading the feed exactly how to use the search signatures. Self-documenting data.

The Patterns Page

The feed is machine-readable. For humans, there's /patterns — a filterable browser with dropdowns for version, category, and framework, plus free text search. Each card shows:

Version badge and category/framework tags
A bilingual summary
Search signatures as copyable code badges
The replacement code in a syntax-highlighted block
Links to the GitHub release and Svelte documentation

It uses the same patterns.ts data file that the feed endpoint reads, so there's a single source of truth. The page is SSR'd on Cloudflare Workers — no client-side fetch needed.

The filters are reactive using Svelte 5's $derived.by(). Changing any dropdown or typing in the search box immediately narrows the visible patterns. The text search matches across titles, summaries, notes, code, and search signatures in both languages.

What's Covered

At the time of this post, there are 34 patterns spanning Svelte 5.0 through 5.55 and SvelteKit 2.10 through 2.55:

Core runes (5.0): $state, $derived, $effect, $props/$bindable, snippets, onclick handlers, .svelte.ts modules, $inspect, $state.raw/.snapshot

Incremental releases: error boundaries (5.3), {#each} without as (5.4), exportable snippets (5.5), MediaQuery class (5.7), Spring/Tween classes (5.8), reactive window values (5.11), ClassValue + object/array class syntax (5.16), $props.id() (5.20), writable $derived (5.25), attachments (5.29), snippet generics (5.30), fromAction() (5.32), getAbortSignal() (5.35), async components (5.36), createContext (5.50), TrustedHTML (5.52), parametric compiler options (5.54), motion type exports (5.55)

SvelteKit: init hook (2.10), transport hook (2.11), $app/state (2.12), async reroute (2.18), getRequestEvent() (2.20), remote functions (2.27), SSR error boundaries (2.54), type-narrowed params (2.55)

Each links to its GitHub release page, so you can trace the exact changelog entry, if and as needed.

Using It with an AI Assistant

The practical use case: you're in a SvelteKit codebase and want to modernize. Tell your AI assistant:

"Fetch https://svelte.cogley.jp/feeds/patterns.json and check what patterns from this feed apply to this repo."

The assistant fetches the feed, reads the search_signatures from each pattern, greps the codebase, and reports which old patterns it found with the modern replacements. No manual searching through docs.

For a more targeted audit:

"Fetch https://svelte.cogley.jp/feeds/patterns.json?since=5.29 and see if we're using any pre-5.29 patterns that have better alternatives now."

You can also filter by what you're migrating from:

"Fetch https://svelte.cogley.jp/feeds/patterns.json?framework=react and show me the patterns relevant to this React-to-Svelte migration."

The feed's _svelte_patterns_meta.usage_hint field tells the assistant exactly how to interpret the data, so it works even without prior knowledge of the feed's structure.

Real-World Results

I pointed Claude Code at the patterns feed across several production repositories and asked it to audit each one. Here's what happened.

Fixes Applied Immediately

Repo	Before	Fix	Files
pub-cogley	`onMount`/`onDestroy` lifecycle, manual `AbortController`, duplicated utils	Converted 19 lifecycle calls to `$effect` across 4 apps, extracted shared utils, added cookie `secure` flag	25
pulse	Custom `window.dispatchEvent('org-switched')` pattern	Replaced with `$state`-based reactive signal in `.svelte.ts` module	7
codex	`$app/stores` imports (`$page`)	Converted to `$app/state` with `$derived()`	2
periodic	`$app/stores` + `writable()` language store	Converted to `$app/state` (9 files) + rewrote language store as `.svelte.ts` with `$state` rune (60 consumers)	70
courier	`$app/stores` + `writable()` language store + unvalidated route params	Converted to `$app/state` (3 files), rewrote language store (9 consumers), added param matchers for route type safety	14

That's 118 files modernized across 5 SvelteKit codebases, but I also applied it to a non-svelte project, and a greenfield project that used the feed as a day-one adoption checklist.

What Was Already Modern

Every repo was already using core Svelte 5 patterns: $state, $derived, $effect, $props, snippets, onclick handlers, use:enhance. The feed correctly identified these as "no action needed" and focused on the gaps — mostly $app/stores → $app/state conversions and lingering writable() stores.

The Greenfield Case: Mame

One repo — mame, an internal learning platform started the same day — used the feed proactively rather than retroactively. Instead of finding legacy code to fix, it used the patterns feed as a kind of checklist for what to adopt from the start. The result: createContext<T>() for type-safe context (eliminated prop drilling across 18 files), $props.id() for SSR-safe form IDs, MediaQuery class for reactive breakpoints, and svelte/reactivity/window for reactive viewport values — all patterns that the existing repos had flagged as "future opportunities" but hadn't adopted yet.

The Nexus Case

One repo — nexus — is a pure Hono API worker with zero .svelte files. The feed audit correctly reported "N/A" for all Svelte patterns. It did find deprecated shared docs containing Svelte 4 examples that had been migrated to another repo, which were cleaned up.

Future Opportunities

Every repo got a tailored list of patterns that are available but not yet adopted — type-narrowed route params (SvelteKit 2.55), SSR error boundaries (2.54), createContext<T>() (5.50), getAbortSignal() (5.35). Not urgent, but now documented as backlog items. The "Not Applicable" column was equally useful — the feed correctly identified cases where patterns don't apply, like getAbortSignal() in repos where fetches are user-triggered button clicks rather than $effect blocks.

Implementation Notes

Feed Endpoints

The feed endpoints are SvelteKit server routes returning json() responses with CORS headers and 1-hour cache. Both are at /feeds/ — a dedicated namespace that won't conflict with page routes.

Version Filtering

The patterns feed supports version filtering via the since query parameter. The implementation uses semver comparison on the since field:

?since=5.54 matches all svelte@5.54.0+ patterns but not sveltekit@ patterns
?since=kit@2.55 matches all sveltekit@2.55.0+ patterns but not svelte@ patterns

This lets you ask "what's new since version X?" for either package independently.

Feed Autodiscovery

Feed autodiscovery is handled by <link rel="alternate" type="application/feed+json"> tags in the SvelteKit layout. Any feed reader that visits any page on the site will discover both feeds automatically.

Bilingual Support

Both feeds support ?lang=ja to return Japanese titles, summaries, and notes where available. The patterns data is bilingual at the source level — every pattern has both title and title_ja, summary and summary_ja.

Layout and Navigation

The patterns page sits alongside the existing home (migration mappings), about, and changelog pages. Feed links appear in the global footer on every page, and the changelog page has a JSON Feed badge in its header. The layout includes theme and language toggles in the nav bar, accessible from every page.

How This Fits Together

The migration guide now has three machine-readable interfaces, each for a different use case:

Interface	Audience	Best for
`/llms-full.txt`	LLMs reading the whole site	"Tell me about Svelte 5 migration"
`/feeds/patterns.json`	AI coding assistants	"Audit this codebase for modernization"
WebMCP tools	Browser-based AI agents	"What's the Svelte equivalent of useEffect?"

The patterns feed fills the gap between "read everything" (llms-full.txt) and "answer one question" (WebMCP). It's the "here's what's actionable" layer — structured enough for automation, browsable enough for humans.

This builds on the original migration guide article and the WebMCP tools implementation. The patterns feed complements WebMCP — WebMCP is for browser-based AI agents interacting with the page, while the JSON Feed is for CLI tools and coding assistants that can fetch URLs directly.

Originally published at cogley.jp

Rick Cogley is CEO of eSolia Inc., providing bilingual IT outsourcing and infrastructure services in Tokyo, Japan.

Cloudflare Dynamic Workers: Sandboxed Code Execution at the Edge

Rick Cogley — Thu, 26 Mar 2026 04:30:42 +0000

I needed to run user-defined JavaScript templates from a database — code that formats RSS feed items into social media posts. The templates could be anything: hand-written, AI-generated, pasted from a blog. Running arbitrary code strings inside my production Worker, with access to D1 databases and R2 buckets, wasn't an option.

Cloudflare's Dynamic Workers, released in March 2026, solved this. They let a parent Worker spawn new Workers at runtime from code strings, each in its own V8 isolate with explicitly controlled access. I wired them into my publishing stack in an afternoon.

The Problem Before Dynamic Workers

If you had a JavaScript function stored in a database and wanted to execute it inside a Cloudflare Worker, you had three options — all bad:

new Function() / eval() — runs the code inside your Worker process, with full access to every binding, every secret, and the open internet. One malicious template and your D1 database, R2 buckets, and API keys are exposed.
String interpolation only — treat templates as dumb mustache-style patterns ({{title}} - {{link}}). Safe, but you can't express logic: no "skip items without titles," no conditional formatting, no length-based truncation.
External execution service — ship the code to a separate sandboxed API. Adds latency, another deployment to maintain, and a network hop that defeats the edge-computing point of Workers.

Dynamic Workers give you option 1's full JavaScript expressiveness with option 3's isolation, at option 2's simplicity. The code runs in a separate V8 isolate on the same machine, with zero access to anything you don't explicitly hand it.

How They Work

The parent Worker creates a new Worker from a code string. Each spawned worker gets its own V8 sandbox, starts in milliseconds, and the parent controls exactly what it can touch.

The API is minimal:

const worker = env.LOADER.load({
  compatibilityDate: '2026-03-21',
  mainModule: 'transform.js',
  modules: { 'transform.js': codeString },
  globalOutbound: null, // block all network access
});

const result = await worker.getEntrypoint().myMethod(data);

Two things matter here:

globalOutbound: null — the spawned worker can't make HTTP requests. No phoning home, no data exfiltration, no SSRF.
Selective binding exposure — the parent decides which bindings (D1, R2, KV) to pass. Pass nothing and the sandbox is a pure function: data in, data out.

How I'm Using Them: Auto-Post RSS Feed Templates

My publishing system (cogley.jp) is a monorepo with a Hono API on Cloudflare Workers, backed by D1, R2, KV, Vectorize, and several Workflows. It handles micro posts, long-form articles, feeds, and syndication to Bluesky, Nostr, and status.lol.

I already had an RSS feed reader with a feeds table that included unused auto_post and auto_post_template columns. The idea was always "when a feed gets a new item, create a post from it."

Before Dynamic Workers, I would have had to hardcode the formatting logic for each feed directly in my Worker — a function like formatEsoliaBlogPost() baked into the deployed code, redeployed every time I wanted to change the output format or add a new feed with different formatting. Now, I store a JavaScript function in a database column, and the cron executes it in a sandbox. Adding a new feed with completely different formatting is an API call, not a deployment.

The Flow

flowchart LR
    A[Cron 15min] --> B[Fetch RSS]
    B --> C{New items?}
    C -- No --> Z[Done]
    C -- Yes --> D[Dynamic Worker
sandbox]
    D --> E{Valid output?}
    E -- null --> F[Mark skipped]
    E -- Yes --> G[Create post]
    G --> H[Generate OG image]
    H --> I[Syndicate to
Bluesky / Nostr / status.lol]

A cron runs every 15 minutes, refreshing subscribed RSS feeds
When new items appear in a feed with auto_post: true, each item goes to a Dynamic Worker
The Dynamic Worker executes the template — a JavaScript function stored in D1
The template returns structured data (content, stream, mood, visibility)
The parent validates the output, creates a post, pre-generates an OG image, and triggers syndication to Bluesky/Nostr/status.lol

The Template

Templates are arrow functions stored in the auto_post_template column. This is the one I'm running for our company's bilingual tech blog:

(item) => {
  if (!item.title) return null; // skip items without titles
  const title = item.title;
  const link = item.link || "";
  const summary = item.summary || "";
  const teaser = summary.length > 150
    ? summary.substring(0, 147) + "..."
    : summary;

  let content = `**${title}**`;
  if (teaser) content += `\n\n${teaser} ☕`;
  if (link) content += `\n\n${link}`;
  content += `\n\n(Japanese version also available on the blog.)`;

  return {
    content,
    stream: "tech",
    visibility: "public",
    mood: "binoculars",
    syndicate_to: ["bluesky", "nostr", "statuslog"]
  };
}

The function receives a plain data object — title, link, summary, content, author, and source feed metadata. It returns what the post should look like, or null to skip the item.

This is the kind of logic that string interpolation can't express. The template makes decisions: skip items without titles, truncate summaries longer than 150 characters at a word-friendly boundary, conditionally include the teaser line, choose a mood and syndication targets. With a mustache-style {{title}} - {{link}} template, I'd need a separate config field for every one of those behaviors — and I'd still be hardcoding the logic in my Worker code. With Dynamic Workers, the template is the logic, and changing it means updating one database row. No redeploy, no code change.

The Security Model

flowchart TB
    subgraph Parent Worker
        A[Template code from D1] --> B[env.LOADER.load]
        F[Validate & sanitize output] --> G[Create post in D1]
    end
    subgraph Dynamic Worker sandbox
        C[Execute template function]
        D[No bindings
No network
No secrets]
    end
    B --> C
    C --> F
    style D fill:#fee,stroke:#c33

The template code could be anything. The sandbox ensures it can't cause harm:

No bindings: zero Cloudflare bindings. No D1, no R2, no KV, no secrets.
No network: globalOutbound: null blocks all outbound HTTP.
Data in, data out: the template receives a plain object and returns a plain object.
Output validation: the parent validates the return value against a strict schema, sanitizes strings, strips control characters, and enforces allowed values for fields like stream and visibility.

If the template throws or returns something invalid, the feed item is marked skipped with a reason. The system moves on to the next item.

Cost

$0.002 per unique worker loaded per day (waived during beta), plus standard CPU time. For a cron that runs a handful of templates a few times a day, this rounds to zero against the AI inference costs I'm already paying for image analysis and content summarization.

Another Use Case: Live Code Migration

I maintain svelte.cogley.jp, an interactive reference for migrating from React, Vue, and Angular to Svelte 5. The site itself is static SSR — all mapping data baked into TypeScript files. But the people using it are actively converting code from one framework to another, and they'd benefit from a "paste your component, get a Svelte 5 version" feature.

Dynamic Workers are how I'd build it:

User pastes a React/Vue/Angular component
The server sends it to Workers AI with a conversion prompt
The AI-generated Svelte code runs in a Dynamic Worker sandbox to verify it parses — no phantom imports, no syntax errors
The validated result goes back to the user

Two layers of untrusted input — user-submitted code and AI-generated output — both handled by the same sandbox. globalOutbound: null blocks the code from reaching the network, and the V8 isolate prevents it from touching anything else on the platform. This pattern applies anywhere you need a "paste your code, get a conversion" tool.

Where They Don't Fit

I evaluated Dynamic Workers across my entire stack. Three places where they're the wrong tool:

Typed application routes — my Hono routes are stable, typed with Drizzle ORM, and benefit from static deployment. Making them dynamic would add indirection for no gain.
Durable Workflows — image processing, syndication delivery, and transcription use Cloudflare Workflows because they're multi-step and retriable. Dynamic Workers are ephemeral — wrong primitive.
"Make everything dynamic" — Dynamic Workers solve a specific problem: runtime execution of variable code. Applying them broadly adds complexity without purpose.

The right use cases are user-configurable transforms and sandboxed execution of untrusted code — places where the logic changes without redeploying, or where you need a hard security boundary between arbitrary code and your platform.

What's Next

I'm building a feed management UI in my authoring app — list subscriptions, toggle auto-posting, edit templates in a code editor. The API endpoints already exist; it's the frontend that needs work.

Beyond that, the same Dynamic Worker pattern applies to syndication formatting (per-platform rules stored in D1, editable without redeploying) and AI content transforms (LLM generates the code, Dynamic Worker executes it, parent validates the output).

Originally published at cogley.jp

Rick Cogley is CEO of eSolia Inc., providing bilingual IT outsourcing and infrastructure services in Tokyo, Japan.

Who Moved My Settings? Automating Vendor Doc Drift Detection

Rick Cogley — Mon, 23 Mar 2026 21:58:16 +0000

Spencer Johnson's Who Moved My Cheese? is about adapting when things change around you. In cloud security compliance, the cheese moves constantly. Microsoft renames a menu. Google moves a toggle to a different admin panel. Your carefully written implementation guide now points to a screen that no longer exists. Your client follows the old steps and hits a dead end.

We built an automated pipeline that crawls vendor documentation weekly, compares it against our internal implementation guides, and flags meaningful drift: renamed UI paths, deprecated features, relocated settings. It runs on Cloudflare Workers with a Durable Workflow, uses Claude for semantic analysis, and costs about 50 cents a week at scale. Here's how.

The Problem: Documentation Drift

We maintain implementation guides for security controls, such as "Enable MFA for Admin Accounts in Microsoft Entra" or "Configure Conditional Access Policies." Each guide has specific, click-by-click instructions referencing particular admin portal locations, feature names, and configuration options.

Cloud vendors update their platforms constantly. Microsoft alone pushes changes to Entra ID (formerly Azure AD) multiple times a month. When they rename a feature or reorganize an admin panel, our guides become incorrect. We call this documentation drift.

Before building this system, drift detection was entirely manual. A consultant would notice a discrepancy during a client engagement, report it, and someone would update the guide. The feedback loop was slow and reactive.

The Architecture: A Three-Gate Pipeline

We wanted something cheap to run, resistant to false alarms, and automated. The solution is a three-gate pipeline where each gate filters out unnecessary work before reaching the next, more expensive step.

Gate 1: RSS Check (Free, Milliseconds)

Microsoft Learn exposes an RSS endpoint that reports page modification dates. Before crawling anything, we check whether the vendor has even published changes since our last run. If the RSS timestamps haven't moved, we skip the entire source. This gate eliminates most checks in a typical week.

Gate 2: Content Hash (Cheap, Seconds)

When RSS indicates something might have changed, we crawl the vendor page and compute a SHA-256 hash of the markdown content. If the hash matches what we stored last time, the page content hasn't actually changed. Maybe the RSS date shifted for editorial reasons, or the page got a cosmetic update. Skip.

Gate 3: AI Drift Analysis (API Cost, Seconds)

Only when the content has genuinely changed do we send it to Claude for semantic comparison against our implementation guide. The AI isn't doing a text diff. It detects specific categories of drift:

UI path changes: "Settings > Security" became "Protection > Authentication"
Feature deprecation: a feature we reference no longer exists
Step reordering: the vendor changed the sequence of configuration steps
New prerequisites: a step now requires something it didn't before
Setting relocation: a toggle moved from one admin panel to another

It deliberately ignores minor wording changes, formatting differences, and additive features that don't affect existing instructions.

Why a Companion Worker?

Our main application runs on SvelteKit with Cloudflare's adapter, which doesn't support Workflow classes or scheduled handlers. So the crawler runs as a separate Worker that shares the same D1 database. Two Workers, one database, clean separation of concerns.

The companion Worker uses Cloudflare Workflows for durability. Each doc source gets its own named steps. If a crawl job fails partway through, the workflow resumes from the last completed step rather than starting over. Durable sleep steps let the Worker wait for asynchronous crawl jobs without burning CPU time.

Dealing with a Flaky API

The Cloudflare Browser Rendering /crawl endpoint is asynchronous and occasionally unreliable. Jobs sometimes error out immediately for no apparent reason. We handle this with:

3 crawl attempts with 20-second backoff between retries
15-second stagger between sources to avoid rate limiting
Polling with durable sleep: the Worker sleeps (zero CPU cost) between poll checks

This brought our success rate from roughly 50% to about 90%. The remaining failures are typically transient and resolve on the next weekly run.

What Drift Detection Looks Like

When the system detects drift, it stores a bilingual summary (English and Japanese) with structured change details. A staff member reviews the flag and either updates the implementation guide or dismisses it as a false positive.

Real drift we've caught so far:

Microsoft deprecated per-user MFA in favor of Conditional Access policies
UI paths in the Entra admin center were reorganized
A grace period for legacy authentication blocking was removed

Each of these would have eventually caused confusion during a client engagement. Instead, we caught them within a week of the vendor change.

Cost

For our current 10 doc sources (5 M365 controls × 2 languages), the weekly cost rounds to zero. At scale (say 120 sources covering Microsoft 365, Google Workspace, and Cloudflare) we estimate about $0.50 per week. Gate 1 and Gate 2 eliminate most of the expensive AI calls.

Component	Weekly Cost
RSS checks (Gate 1)	Free
Browser Rendering crawls	~$0.30
Claude AI analysis (Gate 3)	~$0.15
Worker compute + D1 storage	Free tier
Total (~120 sources)	~$0.50

What's Next

The current system covers Microsoft 365 identity controls. The pipeline is vendor-agnostic. Adding a new doc source is just a database row with a URL and crawl configuration. Next steps:

Expand coverage to remaining M365 controls plus Google Workspace and Cloudflare
Build the review UI so staff can view diffs, approve updates, and track guide versions
Vendor-specific adapters for Gate 1 (Google and Cloudflare have different changelog patterns than Microsoft's RSS)
Automatic guide updates where the AI suggests specific text changes, not just flags

Key Takeaways

Vendor documentation drift is a real operational risk for any team maintaining compliance guides. Catching it doesn't require a complex system. A pipeline that filters aggressively at each stage keeps both costs and false alarms low. Cloudflare's Worker platform, with Workflows for durability and Browser Rendering for crawling, turned out to be a natural fit for this kind of periodic, asynchronous inspection work.

The code runs once a week, costs pocket change, and has already caught real drift that would have burned consultant time. That's a good trade.

Originally published at cogley.jp

Rick Cogley is CEO of eSolia Inc., providing bilingual IT outsourcing and infrastructure services in Tokyo, Japan.

Enabling WebMCP Tools on my SvelteKit Migration Reference

Rick Cogley — Sun, 22 Mar 2026 02:12:51 +0000

An AI agent asks: "What's the Svelte 5 equivalent of useEffect?" Today it has two options — scrape the page HTML and parse it, or fetch api/data.json and filter 100+ items in context. Both work ok, but they both waste tokens.

WebMCP gives our AI agent a third option: call get_svelte_equivalent({ framework: 'react', concept: 'Side Effects' }) and get a structured answer directly. The data is the same. The interface is purpose-built for agents.

What WebMCP Is

WebMCP is a W3C Community Group Draft that adds navigator.modelContext to browsers. It lets websites register MCP tools — the same protocol that powers Claude's tool use, Cursor's context, and other agent frameworks — directly in a webpage. An AI agent browsing the site can discover and call those tools without scraping.

Chrome Canary (146+) has WebMCP behind a flag, and Microsoft Edge appears to support it out of the box — no flags or settings needed. For other browsers, @mcp-b/global from the MCP-B project fills in, until native support ships. Don't confuse this with Anthropic's MCP server protocol — WebMCP is a client-side browser API that happens to speak the same message format.

The App

My site svelte.cogley.jp is a migration reference showing how concepts from React, Vue, Angular, and now Svelte 4 map to Svelte 5. There are 120+ structured mappings across four categories: overview, syntax, architecture, and ecosystem. Each mapping has a concept name, source framework code, Svelte equivalent code, notes, doc links, and bilingual support (English/Japanese, well, because I can).

The data already has machine interfaces: a JSON API at /api/data.json, content negotiation via Accept: text/markdown, and an llms.txt describing the site for crawlers. WebMCP adds another layer — typed tools that agents can discover and call in-page without fetching or parsing anything.

Loading Strategy

The polyfill weighs ~285KB. Most visitors are humans browsing migration cards, not AI agents calling tools — so shipping it in the initial bundle would be wasteful. Dynamic import:

onMount(async () => {
  theme.init();
  language.init(data.lang);

  // Force polyfill mode — Chrome Canary's native modelContext is
  // incomplete (missing listTools/registerTool), which crashes the
  // native adapter. Disable auto-init, wipe, then reinitialize.
  const win = window as unknown as Record;
  win.__webModelContextOptions = { autoInitialize: false };
  const { cleanupWebModelContext, initializeWebModelContext } =
    await import('@mcp-b/global');
  cleanupWebModelContext();
  try {
    Object.defineProperty(navigator, 'modelContext', {
      value: undefined, configurable: true, writable: true,
    });
  } catch { /* non-configurable — already cleaned */ }
  initializeWebModelContext();

  const { registerMigrationTools } = await import('$lib/webmcp');
  registerMigrationTools();
});

Vite code-splits the polyfill into its own chunk. The __webModelContextOptions flag prevents the module's auto-initialization from crashing on browsers (like Chrome Canary) where the native navigator.modelContext exists but is incomplete — missing listTools() and registerTool(). After wiping the incomplete native API, initializeWebModelContext() installs the full polyfill. On Edge and browsers without a native API, cleanupWebModelContext() is a no-op and the polyfill installs normally.

The registerMigrationTools() import is dynamic too, keeping tool definitions out of both the server bundle and the initial page load.

Designing the Tools

Six read-only tools answer questions that AI agents might want to do, like "what's the Svelte equivalent of X?"

search_mappings

Full-text search across concepts, code, and notes. Same filter logic as the UI's search box:

mc.registerTool({
  name: 'search_mappings',
  description: 'Search migration mappings by keyword...',
  inputSchema: {
    type: 'object',
    properties: {
      query: { type: 'string', description: 'Search keyword' },
      framework: { type: 'string', enum: ['react', 'vue', 'angular', 'svelte4'] },
      category: { type: 'string', enum: ['overview', 'syntax', 'architecture', 'ecosystem'] },
      lang: { type: 'string', enum: ['en', 'ja'] },
    },
    required: ['query'],
  },
  annotations: { readOnlyHint: true },
  execute: async (args) => {
    // Filter pool by framework/category, then substring-match on query
    // Return structured JSON with framework/category context per match
  },
});

An agent searching for "useState" gets React entries; searching for "routing" gets results across all four frameworks. The optional framework and category filters let agents narrow results when they already know what they're looking for.

get_svelte_equivalent

Direct lookup: give it a framework and concept name, get the best match. Uses exact match first, then substring fallback. If the agent asks for { framework: 'react', concept: 'Reactive State' }, it gets the $state mapping with full code examples and notes.

list_ecosystem_gaps

Items where the to field contains "No equivalent" or "⚠️". This is the kind of query that's awkward to express via JSON filtering but natural as a tool call: "What can't I do in Svelte that I can do in React?"

The Other Three

get_site_info — overview: frameworks, categories, total count, API URLs. The "hello world" tool.
get_changelog — recent updates, bilingual, with configurable limit.
compare_frameworks — side-by-side: how React, Vue, Angular, and Svelte 4 each handle the same concept. An agent comparing "Reactive State" gets useState vs ref() vs signal() vs let count = 0 → $state in one call.

The Registration Module

The entire module is ~180 lines of TypeScript. Shared helpers handle filtering and matching:

function applyFilter(pool: MappingItem[], query: string): MappingItem[] {
  if (!query.trim()) return pool;
  const q = query.toLowerCase();
  return pool.filter(
    (item) =>
      item.concept.toLowerCase().includes(q) ||
      item.concept_ja?.toLowerCase().includes(q) ||
      item.from?.toLowerCase().includes(q) ||
      item.to?.toLowerCase().includes(q) ||
      item.notes?.toLowerCase().includes(q) ||
      item.notes_ja?.toLowerCase().includes(q) ||
      item.checklist?.some((s) => s.toLowerCase().includes(q)) ||
      item.checklist_ja?.some((s) => s.toLowerCase().includes(q))
  );
}

Same logic that drives the $derived block in +page.svelte. The UI and the tools search identically — one filter function, two consumers.

Every tool returns MCP's standard content format ({ content: [{ type: 'text', text: JSON.stringify(...) }] }) and carries annotations: { readOnlyHint: true }. Query only, no mutations.

Testing

Microsoft Edge works out of the box. Chrome Canary needs the WebMCP flag (chrome://flags → "WebMCP for testing"). Alternatively, install the MCP-B extension. Open the console:

// List tools
navigator.modelContext.listTools()
// → Array of 6 tools with names, descriptions, input schemas

// Search for useState
await navigator.modelContext.callTool({
  name: 'search_mappings',
  arguments: { query: 'useState' }
})

// Direct lookup
await navigator.modelContext.callTool({
  name: 'get_svelte_equivalent',
  arguments: { framework: 'react', concept: 'Reactive State' }
})

// Compare across frameworks
await navigator.modelContext.callTool({
  name: 'compare_frameworks',
  arguments: { concept: 'Reactive State' }
})

In browsers without native support, the polyfill loads silently with no visible UI change and no console errors. Here it is in Chrome Canary, but I tested in Edge too and it worked without any special settings:

Updating llms.txt

I added a WebMCP section to llms.txt listing all six tools with their parameters. An agent that discovers the site via llms.txt now knows it can call tools directly — it doesn't have to guess whether the site supports WebMCP or fall back to fetching JSON.

Update: Svelte 4 → 5 Upgrade Data

22 Feb 2026 — I added Svelte 4 as a fourth source framework. This one's different from the other three — it's not a cross-framework migration, it's an upgrade guide for developers already on Svelte who need to move from v4 to v5 (runes, snippets, new event syntax, stores → reactive classes).

The data includes 25 new mappings: 4 overview items, 12 syntax mappings, 5 architecture patterns, and 4 ecosystem entries. The overview category has a new card type — a ChecklistCard — that renders a step-by-step migration checklist with numbered steps instead of the usual two-column code comparison. The checklist covers everything from npm install svelte@5 through running sv migrate to testing $$props edge cases.

A new checklist field on MappingItem holds the step arrays, with checklist_ja for Japanese translations. All four machine-readable interfaces were updated:

WebMCP tools — search_mappings and get_svelte_equivalent now accept framework: 'svelte4'; search covers checklist text; localizeItem returns the checklist array
llms-full.txt — Svelte 4 section renders checklist steps as numbered lists
llms.txt — framework list and tool descriptions updated
data.json — includes the full svelte4 data structure automatically

An agent can now do things like get_svelte_equivalent({ framework: 'svelte4', concept: 'Props' }) to learn that export let prop → let { prop } = $props(), or search_mappings({ query: 'stores', framework: 'svelte4' }) to find the stores → reactive classes migration path.

What It Cost

The registration module is ~200 lines of TypeScript, with six tools. Zero bytes added to the initial page bundle of https://svelte.cogley.jp because everything loads dynamically — the polyfill chunk (429KB) only fires if the browser doesn't have native support yet.

The migration data was already structured and queryable. Now — with four frameworks and 120+ mappings including the Svelte 4 → 5 upgrade path — the site has an interface that AI agents can use without scraping.

Originally published at cogley.jp

Rick Cogley is CEO of eSolia Inc., providing bilingual IT outsourcing and infrastructure services in Tokyo, Japan.

Markdown for Agents on SvelteKit + Cloudflare Workers

Rick Cogley — Sun, 22 Mar 2026 02:12:42 +0000

The AI crawl-and-summarize wave has landed. Google's Gemini, OpenAI's GPT, Anthropic's Claude, Perplexity — they're all hitting your site. If you serve them HTML, they waste tokens parsing `` soup. If you serve them markdown, they get clean context immediately.

Cloudflare published a guide to serving markdown for AI agents using Transform Rules and their AI gateway. Michael Wolson then wrote an excellent adaptation for the free plan using Transform Rules to set headers that content-negotiate at the edge.

I run SvelteKit on Cloudflare Workers. My situation is different — and simpler. Here's how I implemented it and why no Transform Rules were necessary.

The Problem with Transform Rules on Workers

Wolson's approach is clever: use a Cloudflare Transform Rule to inject a custom header based on the Accept header, then check that header in your application to decide the response format. This solves a real problem for static sites: CDN caching. Without differentiated cache keys, a cached HTML response gets served to a markdown-requesting bot, or vice versa.

Workers don't have this problem. Every request executes the Worker — there's no CDN cache layer sitting in front of dynamic routes on Pages Functions. The Worker sees the raw Accept header directly and can branch on it before any rendering happens.

Architecture

The implementation hooks into SvelteKit's server hooks — the middleware layer that runs before any route handler.

`mermaid flowchart TD A[Incoming Request] --> B{Accept: text/markdown? or ?format=md} B -->|Yes| C[handleMarkdownRequest] C --> D{Route matched?} D -->|Yes| E[Fetch API data via Service Binding] E --> F[Format as markdown] F --> G[Return Response text/markdown + headers] D -->|No| H[Fall through to SSR] B -->|No| H H --> I[Normal HTML Response] G --> J[Add security headers] I --> J J --> K[Response to client] `

The key insight: all my content already lives in the API with raw markdown fields. Posts have content (markdown). Articles have content (markdown). Pages have content (markdown). No HTML-to-markdown conversion needed — I just skip the rendering step entirely.

Detection

Two signals trigger markdown responses:

The Accept: text/markdown header (per the emerging convention)
A ?format=md query parameter (for easy browser testing)

`typescript function wantsMarkdown(request: Request): boolean { if (request.headers.get('accept')?.includes('text/markdown')) return true; const url = new URL(request.url); return url.searchParams.get('format') === 'md'; } `

The Hook

In hooks.server.ts, the markdown check runs after legacy redirects but before resolve(event) — meaning SvelteKit never renders any Svelte components for markdown requests:

`typescript if (wantsMarkdown(event.request)) { const mdResponse = await handleMarkdownRequest(event); if (mdResponse) { // Security headers still apply mdResponse.headers.set('X-Content-Type-Options', 'nosniff'); mdResponse.headers.set('X-Frame-Options', 'DENY'); // ... return mdResponse; } } // Unmatched routes fall through to normal HTML const response = await resolve(event); `

Routes without a markdown handler (like /security or /tweet-archive) fall through to normal SSR. No 406 errors, no broken pages.

Route Handlers

Each route is a regex pattern matched against the pathname, paired with a handler that fetches from the API and formats the response:

Route	Data Source
`/`	Recent posts + presence status
`/now`	Full /now page data
`/posts`	Published micro posts (last 50)
`/posts/:slug`	Single post — raw `content` field
`/articles`	Published article list
`/articles/:slug`	Single article — raw `content` field
`/pages/:slug`	Single page — raw `content` field

Individual content pages return the markdown as-is with minimal front matter:

`markdown

Article Title

Published: 2026-02-18 · Stream: tech
URL: https://cogley.jp/articles/some-slug

[raw markdown content from API]
`

List pages provide a structured index with truncated previews and URLs.

The Full Dump: /llms-full.txt

For agents that want everything at once, /llms-full.txt returns all articles, all pages, the now page, and the 50 most recent posts stitched into a single markdown document. This endpoint always returns markdown regardless of the Accept header — it's explicitly for machine consumption.

Combined with the existing /llms.txt (which describes the site structure and available sections), agents have a complete discovery path:

`mermaid flowchart LR A[Agent discovers site] --> B[GET /llms.txt] B --> C[Understands site structure] C --> D{Need everything?} D -->|Yes| E[GET /llms-full.txt] D -->|No| F[GET /articles/specific-slug Accept: text/markdown] `

Token Estimation

Every markdown response includes an x-markdown-tokens header with a rough token count estimate (content.length / 4). It's not precise — real tokenization varies by model — but it gives agents a quick way to gauge response size before processing.

Why This Approach Works for Workers

The Cloudflare blog and Wolson's approach both solve a caching problem that Workers don't have:

Concern	Static/CDN Sites	Workers/Pages Functions
CDN cache collision	Real problem — same URL, different Accept	Non-issue — Worker always executes
Transform Rules needed	Yes, to differentiate cache keys	No
`Vary: Accept`	Insufficient alone (CDN ignores it)	Works correctly (no CDN layer)
Implementation	Edge rules + origin logic	Just origin logic

Setting Vary: Accept is still good practice for HTTP correctness, but it's not load-bearing the way it would be on a CDN-cached static site.

Serving the Profile Site Too

My profile site at rick.cogley.jp uses the same pattern. The profile sections only store content_html (not raw markdown), so the handler uses stripHtml() to extract clean text. Not as rich as raw markdown, but vastly better than HTML tags for an AI agent trying to understand who I am.

Testing It

`bash

Markdown via Accept header

curl -s -H "Accept: text/markdown" https://cogley.jp/now

Markdown via query param

curl -s "https://cogley.jp/now?format=md"

Check headers

curl -sI -H "Accept: text/markdown" https://cogley.jp/posts

Full site dump

curl -s https://cogley.jp/llms-full.txt

Normal HTML (no markdown signal)

curl -s https://cogley.jp/now
`

What I'd Do Differently

If I were building this from scratch, I'd store all content as markdown and render HTML on demand — which is essentially what this site already does. The /api already has markdown fields everywhere because that's what the editor produces. The HTML rendering happens in SvelteKit route handlers using marked.

For sites where content is HTML-first (CMS output, rich text editors), you'd need an HTML-to-markdown conversion step. Libraries like turndown handle this, but the output won't be as clean as source markdown. If you're designing a new system, store the markdown.

References

- llms.txt specification

Originally published at cogley.jp

Rick Cogley is CEO of eSolia Inc., providing bilingual IT outsourcing and infrastructure services in Tokyo, Japan.

Migrate to Svelte 5 — An Interactive Reference for Framework Refugees

Rick Cogley — Sun, 22 Mar 2026 02:12:29 +0000

Do you feel the same? You've been working in React (or Vue, or Angular) for years, shipping production code, wrestling with dependency arrays, wrapping vanilla JS libraries in framework-specific adapters, and wondering why your node_modules weighs more than your actual appl. Then you hear about Svelte 5 and its runes — $state, $derived, $effect — and something clicks. You want to try it, but the migration path feels pretty rocky.

That's the gap my new site is designed to fill.

What's svelte.cogley.jp

It's an interactive, side-by-side reference that maps concepts — not just syntax — from React, Vue, and Angular to Svelte 5 and SvelteKit. It's kind of a "Rosetta Stone" for frontend frameworks: you pick your source language (React, Vue, or Angular), choose a category (overview, syntax, architecture, or ecosystem), and see exactly how each concept translates. I've been using Svelte so it assumes you do, too.

Every mapping includes code examples on both sides, with explanatory notes that capture the why, not just the what. The site also tries to flag ecosystem gaps honestly — places where Svelte doesn't have a mature equivalent yet, like native mobile — so you're making informed decisions rather than discovering surprises mid-migration.

The four lenses

The reference is organized into four categories, each designed around a different kind of question a migrating developer asks:

Overview covers philosophy, migration strategy, and the fundamental architectural differences. This is where you learn that Svelte is a compiler (not a runtime), that SvelteKit is to Svelte what Next.js is to React, and that incremental migration is perfectly viable — you don't need a Big Rewrite.

Syntax is the phrasebook. useState becomes $state. useMemo becomes $derived. Vue's ref() and .value unwrapping disappears entirely. Angular's @Input() decorators become plain destructured $props(). Each card shows the before and after, with some notes explaining the conceptual difference.

Architecture maps the structural patterns: file-based routing, server data loading, form handling, middleware, environment variables. SvelteKit's +page.server.ts / +page.svelte convention is explained relative to Next.js pages, Nuxt's useFetch, and Angular's route guards and services.

Ecosystem is the library mapping table. State management, data fetching, UI components, auth, animation, i18n, testing, charts — each row tells you the Svelte equivalent and assesses maturity. Gaps are flagged visually with badge counts, so you can see at a glance how many holes exist for a given framework. Some answers are satisfying (shadcn-svelte is a near 1:1 port of shadcn/ui), and some are frank (there is no React Native equivalent for Svelte, at least yet).

Bilingual

The entire site works in English and Japanese. Language is auto-detected from your browser's Accept-Language header on first visit, and you can toggle between EN/JA at any time. All concept names, explanatory notes, and UI chrome are fully translated. The site also supports dark and light themes, persisted across visits. My personal site is mostly English but here's a brief intro in Japanese:

日本語の概要: svelte.cogley.jp は、React・Vue・AngularからSvelte 5とSvelteKitへの移行を支援するインタラクティブリファレンスサイトです。構文だけでなく、アーキテクチャやエコシステムの概念を並べて比較でき、日本語と英語の両方で利用可能です。ブラウザの言語設定を自動検出し、ダーク/ライトテーマにも対応。SvelteKit + Cloudflare Workersで構築されており、ターゲットフレームワーク自体で作られた「ドッグフーディング」サイトでもあります。

Dogfooding all the way down

The site itself is built with SvelteKit, deployed as a Cloudflare Worker. It uses Svelte 5 runes ($state, $derived, $effect), scoped CSS (no Tailwind), server-side language detection via hooks.server.ts, and Phosphor icons. There's no database and no tracking — all content lives in a single TypeScript data file. It's a working example of the patterns it teaches.

The font pairing is Murecho for body text (a bilingual-friendly Google Font) and Monaspace Krypton for code blocks (self-hosted). Both choices are intentional: Murecho handles Japanese and Latin text gracefully at the same weight, and Monaspace's texture healing makes code comparisons easier to scan.

Why not just read the Svelte docs?

The official Svelte docs are excellent — for Svelte. But if you're coming from React, you don't think in Svelte terms yet. You think in useEffect and useContext and JSX ternaries. You need a translator that speaks your source language, maps it to the destination, and explains the differences in context. That's what this site tries to do.

Migration docs also tend to go stale fast. Because all the content in this reference lives in one data file (src/lib/data.ts), updates are a single-file edit, and the deployment is automated via GitHub Actions. It's designed to stay current as Svelte 5 evolves.

Try it

Visit svelte.cogley.jp, pick your framework, and start exploring. If you find a mapping that's missing or wrong, please make a comment on this article.

Latest: Auto-Updated Project Showcase

The site now exposes a public changelog API at /api/changelog.json, which returns the latest update date and change summary in a machine-readable format. This powers a new "Projects" section on
cogley.jp/now and a "Side Projects" card on rick.cogley.jp, both of which automatically display the most recent update without any manual edits. The changelog data is fetched server-side at render time, so the latest update date stays current as I push changes to the migration reference.

Built by Rick Cogley in Tokyo. SvelteKit + Cloudflare Workers. No tracking, no ads, just framework translation, yes.

Originally published at cogley.jp

Rick Cogley is CEO of eSolia Inc., providing bilingual IT outsourcing and infrastructure services in Tokyo, Japan.

The AI vs Creator Dilemma

Rick Cogley — Sun, 22 Mar 2026 02:12:17 +0000

The web runs on a fundamental bargain: creators publish content, readers consume it, and somewhere in between, value flows back—through advertising, subscriptions, or traffic that converts to business opportunities. AI has upended this equation in ways we're only beginning to understand.

This week brought a crystallizing and sobering moment: Tailwind CSS laid off 75% of its engineering team despite being more popular than ever. The framework powers the design of sites for NASA, Shopify, and countless others. We hear revenue dropped 80%, docs traffic fell 40%. The driver here wasn't quality or competition, but rather AI coding assistants answering questions without anyone visiting the docs.

If your business model depends on people visiting your content, the Tailwind situation should be a wake-up call. This is a preview of what's coming.

The Value Chain Has Broken

Think of how things used to work. A front end developer has a question about Tailwind utility classes as they are building their site. They search, land on tailwindcss.com, find an answer, and maybe notice Tailwind Plus and decide to buy it. We did. The documentation itself has been both the product support and the marketing funnel.

Now? The same developer probaby asks Cursor, Gemini or Claude Code, getting an answer instantaneously without ever even leaving their coding editor. The question gets answered, Tailwind gets used, but Tailwind Labs sees no traffic, no views of paid product landing pages, and therefore no business conversion opportunities.

The huge and bitter irony here is that the AI models that the coding assistants use were trained on this same documentation. And the value flowed in one direction only.

Two Responses to the Same Problem

The divergence in how popular projects are responding reveals a genuine philosophical split.

The Embrace Strategy: Svelte

The Svelte team appears to have taken a different path. As part of Advent of Svelte 2024, they introduced comprehensive AI support through standardized llms.txt documentation files. I heard on a podcast that their docs now include multiple formats — full for comprehensive access, and even distilled versions optimized for use in an AI agent, with a limited "context window".

Svelte is also helping devs develop better Svelte 5 code, via a dedicated MCP (Model Context Protocol) server that can be leveraged by AI coding assistants. The MCP provides tools for listing documentation sections, retrieving relevant docs on demand, and even a svelte-autofixer that analyzes generated code for issues and best practices. For example, you can easily add it to Claude Code with a single command: npx sv add mcp.

This represents the logical endpoint of the "embrace" philosophy: don't just make your documentation available to AI—build infrastructure that makes AI better at your ecosystem. It is a feedback loop: developers using Claude Code or Codex to scaffold Svelte projects will have better experiences because of the MCP, leading to more Svelte adoption.

Whether this translates to sustainable revenue for the Svelte team remains an open question. But so far, it's a fundamentally different bet than Tailwind is making.

The Protect Strategy: Tailwind

When a community member submitted a pull request adding llms.txt support to Tailwind's documentation site, founder Adam Wathan rejected it. Not because he opposes the feature in principle, but because he's trying to save his business first.

His explanation was raw:

"The reality is that 75% of the people on our engineering team lost their jobs here yesterday because of the brutal impact AI has had on our business. And making it easier for LLMs to read our docs just means less traffic to our docs which means less people learning about our paid products and the business being even less sustainable."

You can see that the discussion thread got a bit heated - some called him short-sighted, others pointed out the irony: AI companies worth billions built products trained on freely available documentation, then redirected the value that documentation used to capture. Well of course they did, and while both sides are rational I think, neither is entirely right.

The Attribution Gap

Here's where I can't help but get a bit cynical. Some AI providers do indeed cite their sources. For example, Anthropic includes citations in its responses when Claude uses web search, linking back to the original content. And while I think that's a step in the right direction, the citation alone doesn't solve the problem.

A link in a footnote doesn't generate the traffic, engagement, or conversion opportunities that someone actually reading your content does. It's better than nothing I guess, but people are getting everything neatly packaged by AI, so there is necessarily going to be less focus on where that information came from. But a link is somehow not the same as what was lost.

The core issue is that content has become training data and retrieval source material without the consent, compensation, or even acknowledgment of the people who created it. Your blog post, your documentation, your carefully crafted tutorial, there it goes, getting fed into a model that generates revenue for someone else. Then again, maybe it's the "same as it ever was", thinking of Google's ad revenue model.

Cloudflare's Interesting Bet

Cloudflare has been building toward something potentially significant. In September 2024, they announced AI Audit—tools to see how AI bots access your content and make informed decisions about blocking or allowing them. On July 1, 2025, their "Content Independence Day", they rolled out "Pay per Crawl" in private beta, a marketplace where content creators can set prices for AI crawlers to access their material. They also became the first major infrastructure provider to block AI crawlers by default on new domains.

The technical mechanism uses HTTP 402 (Payment Required), a status code that's been defined since HTTP 1.1 (that's a long time ago) but rarely used. When an AI crawler requests content, publishers can return either the content with 200 OK, or a 402 with pricing information. Cloudflare acts as the payment intermediary. Major publishers including Condé Nast, TIME, The Associated Press, and Fortune have signed on.

It's clever, but I'm skeptical it will actually work. Consider the economics:

AI companies are already operating at significant losses
Investors expect returns, not new expense categories
The largest AI players have already scraped most of the open web
Future training may shift toward synthetic data and licensed premium sources

The power asymmetry is stark: a handful of well-funded AI companies have enormous leverage, while millions of individual creators have almost none. Cloudflare's marketplace assumes AI companies will voluntarily participate in paying for content they can often get just by scraping, anyway. That's a bad bet on goodwill from in-the-red organizations whose business models require a zero to extremely low content cost.

The Real Stakes

What happens if we get this wrong?

The optimistic case: A sustainable model emerges. Content creators get compensated when AI uses their work. Quality content continues to be produced because there's economic incentive to produce it. The AI ecosystem and the content ecosystem achieve symbiosis.

The pessimistic case: Value extraction continues until the sources dry up. Independent creators stop publishing detailed technical content because there's no return. Documentation becomes shallow and defensive. AI models eventually degrade because the content they depend on stops being created.

We've seen this pattern before. Every ad-supported content model eventually collapsed into a race to the bottom—clickbait, SEO gaming, engagement farming. The question is whether AI will accelerate that collapse or create pressure for something better.

My Personal Choice: Selective Participation

For my own content, I've decided to participate selectively. I'll use Cloudflare's tools to block AI crawlers that don't cite sources. For crawlers that do attribute (like the ones that power Claude's web search with proper citations) I'm willing to have my content accessible to AI.

This isn't a principled, really, it's just pragmatic self-defense. If my articles are going to be used, I want at least the acknowledgment of where that information came from. A citation that might lead someone back to the original source. A thin thread connecting the AI's answer to the human who wrote it.

The llms.txt standard represents something interesting: creators proactively optimizing for AI consumption rather than just having their content scraped. But until there's real compensation, I'm not interested in making extraction more efficient for systems that give nothing back.

What Would Actually Help

If I could design it, this is what I think a better system might look like:

Mandatory attribution with real weight: Not just a footnote, but prominent source linking in AI responses. Make the citation as visible as the answer itself. This is a decision about UX that AI companies can make, keeping the content's origin front and center.
Revenue sharing based on actual usage: Track when specific content informs AI responses. Pay creators proportionally. Perplexity has started doing this with their Publisher Program, though the amounts are modest.
Opt-in training with compensation: Clear consent mechanisms for whether content can be used for training vs. just retrieval, with different compensation structures for each.
Crawler transparency: Standardized identification of AI crawlers, their intended use (training vs. retrieval), and their citation policies. Let creators make informed decisions.
Small creator access to deals: Right now, licensing deals go to News Corp and the New York Times. The long tail of creators—the millions of blog posts and tutorials and documentation pages that AI actually depends on—get nothing.

The Inevitable Adaptation

The web is going to change. That's not a prediction; it's already happening. The question is whether that change serves creators, AI companies, or both.

I'm not anti-AI. I use Claude extensively for my own work and am integrating it and other generative AI into my firm eSolia's ops. But I want to participate in an ecosystem where value flows both directions, where the intelligence I consume is matched by fair treatment of the intelligence I create.

For now, that means blocking bad actors, allowing good ones, and watching carefully to see which category various AI providers end up in. It means supporting efforts like Cloudflare's Pay per Crawl even while doubting they'll achieve scale. It means engaging with the llms.txt conversation while remaining skeptical of optimization that primarily benefits extractors.

The old web had its problems. The new web is still being written. I'd like some say in what we write.

This article reflects one creator's perspective on the rapidly evolving relationship between AI systems and content creators. The Tailwind CSS situation broke on January 6, 2026, with details from Adam Wathan's statements on GitHub and his "We had six months left" episode of the Adam's Morning Walk podcast.

Resources

Tailwind CSS situation:

GitHub PR #2388 - The llms.txt pull request and Adam Wathan's response
"We had six months left" - Adam Wathan's podcast episode discussing the layoffs

Cloudflare's AI efforts:

Introducing Pay per Crawl - Cloudflare's official announcement (July 2025)
Introducing AI Crawl Control - General availability announcement with 402 customization
TechCrunch coverage - Independent analysis of Pay per Crawl

AI integration approaches:

llms.txt specification - The proposed standard for AI-friendly documentation
Svelte LLM documentation - Example of comprehensive llms.txt implementation
Svelte MCP Server - MCP server helping AI assistants write better Svelte code

Originally published at cogley.jp

Rick Cogley is CEO of eSolia Inc., providing bilingual IT outsourcing and infrastructure services in Tokyo, Japan.

A Bowl of Renewal: Nanakusa-gayu

Rick Cogley — Sun, 22 Mar 2026 02:12:03 +0000

A Bowl of Renewal: Nanakusa-gayu on January 7th

Today marks Jinjitsu no Sekku (人日の節句)—the Festival of Humanity, one of the five sacred seasonal festivals in Japan. And with it comes one of the gentlest traditions in the Japanese calendar: nanakusa-gayu, the seven herbs rice porridge.

There's something almost paradoxical about this dish. After the richness of osechi-ryori, the toasts of sake, and the festive indulgence of the New Year period, we return to something deliberately plain. A simple rice porridge with seven wild herbs. Steam rising from a bowl in the morning.

The Seven Herbs: A Poem You Can Eat

The seven spring herbs (haru no nanakusa) have been memorized for generations through a 5-7-5-7-7 waka rhythm—the same meter as classical Japanese poetry:

Seri, nazuna

Gogyō, hakobera

Hotoke no za

Suzuna, suzushiro

Kore zo nanakusa

In English, these translate roughly to:

Seri (芹) — Japanese parsley / water dropwort
Nazuna (薺) — shepherd's purse
Gogyō (御形) — Jersey cudweed
Hakobera (繁縷) — chickweed
Hotoke no za (仏の座) — henbit / nipplewort
Suzuna (菘) — turnip
Suzushiro (蘿蔔) — daikon radish

The fact that this knowledge persists as poetry rather than a mere list tells you something Japanese culture, it's much easier to memorize something when it's a poem or song. My daughter asked if I knew this saying, as she rattled it off. I replied "you grew up here" but it was kind of a weak response, so I'm writing this as a kind of penance.

Little Cultural Aspects Make a Life

Some might dismiss nanakusa-gayu as a quaint relic, an optional tradition in an age of convenience store breakfasts and global cuisine. And technically, yes—skipping it won't end your world.

But here's my view: culture is the world we live in. It's the accumulated texture of human experience, the small rituals that transform mere existence into something richer. The difference between a life with nanakusa-gayu and one without isn't life or death, but to me, it's far more interesting to have small traditions like this.

When you sit down to a bowl of herb porridge on January 7th, you're participating in something that stretches back over a thousand years to Heian-era aristocrats, who themselves adapted it from Chinese traditions even older. You're not just having breakfast—you're briefly touching the same moment that countless generations have touched before you. I think it's pretty cool.

Speaking of culture, the current season in the 72 microseasons of Japan also reference parsley:

芹乃栄 Seri sunawachi sakau, Parsley flourishes

The Practical Wisdom

The traditional explanation holds that nanakusa-gayu "wards off evil spirits and prevents all illness" (jaki wo harai manbyō wo nozoku).

The modern interpretation? Your stomach probably needs a break after a week of festive eating, and these early spring greens provide vitamins and minerals that heavy New Year dishes lack. Both explanations point to the same wisdom: reset, restore, begin again.

Make It Your Own

Here's something freeing: you don't need to source all seven traditional herbs. The spirit of the dish matters more than botanical exactness. Use what's in your refrigerator—spinach, mitsuba, komatsuna, or whatever greens are fresh and available. Create your own original nanakusa-gayu. But also note, you can buy a "nanakusa set" of these greens at typical supermarkets, to chop up yourself.

And if you use leftover rice from your freezer? You're honoring another Japanese value: mottainai, the reduction of waste. The old traditions and modern sustainability turn out to walk the same path.

How to Make Nanakusa-gayu

The preparation is almost meditative in its simplicity:

Cook rice into a loose porridge (okayu), about 1 part rice to 5-7 parts water
Finely chop your seven herbs (or your chosen greens)
Add them to the porridge near the end of cooking
Season simply with salt
Eat in the morning, ideally while the house is still quiet

That's it. No complex technique. No impressive plating. Just warmth, greenness, and the first taste of spring in the coldest part of winter.

Happy Jinjitsu no Sekku. May your year be gentle on the stomach and rich in meaning.

Originally published at cogley.jp

Rick Cogley is CEO of eSolia Inc., providing bilingual IT outsourcing and infrastructure services in Tokyo, Japan.

What Is Kanreki? Japan's 60th Birthday Tradition Explained

Rick Cogley — Sun, 22 Mar 2026 02:11:48 +0000

The morning of January 1st, 2026, I turned 60 — a milestone that in Japan carries a significance far beyond the usual birthday fanfare. I celebrated my kanreki (還暦), one of the most meaningful longevity celebrations in Japanese culture.

What is Kanreki?

The word itself tells the story: kan (還) means "return" and reki (暦) means "calendar." At 60, you've completed a full cycle of the traditional East Asian zodiac calendar and symbolically returned to your birth year.

Think of it like an odometer rolling over. The zodiac system combines 12 animals (the jūnishi) with 5 elements (wood, fire, earth, metal, water), each appearing in both yin and yang forms. Multiply these together — 12 × 5 = 60 — and you get the complete cycle. When you turn 60, the same animal-element combination that marked your birth year comes around again.

I was born in 1966, the Year of the Fire Horse — hinoe-uma (丙午) in Japanese. This year, 2026, is once again hinoe-uma. The circle is complete.

The Fire Horse's Shadow

Being born hinoe-uma carries a peculiar weight in Japan. An old superstition holds that women born in Fire Horse years possess a fierce, strong-willed temperament that brings misfortune to their husbands—even, in darker versions of the tale, driving them to early graves. The belief is baseless, of course, but its demographic impact was strikingly real: Japan's birth rate dropped by roughly 25% in 1966 as families avoided having daughters in that year.

The superstition traces back centuries, reinforced by kabuki plays and folk tales featuring hinoe-uma women as dangerous figures. It's a sobering example of how cultural narratives can shape actual human decisions at a national scale.

For those of us born male in 1966, the stigma never applied directly—though we still carry that fire-horse energy, for whatever that's worth. And now, with 2026 marking the first hinoe-uma year since 1966, demographers are watching closely to see whether the old belief still influences family planning in modern Japan.

The Red of Rebirth

The most recognizable symbol of kanreki is the akai chanchanko — a red padded vest traditionally worn by the celebrant, often paired with a red cap called an eboshi or zukin. Red carries deep meaning here: it's the color associated with babies in Japan, representing a symbolic rebirth. Having completed one full life cycle, you begin another.

There's also a practical folk belief at work. Red was thought to ward off evil spirits and illness—protection that seemed especially appropriate as one entered the later chapters of life.

A Tradition Transformed

Kanreki's meaning has shifted over generations. When life expectancy was shorter, reaching 60 genuinely meant entering old age. The celebration acknowledged that you'd lived a full life and were now an elder deserving of respect and, frankly, rest.

Today, with people commonly living into their 80s and 90s, 60 feels less like an ending and more like a transition—perhaps the start of a new chapter rather than the final pages. Many people are still working, traveling, and starting new projects at 60. The "rebirth" metaphor feels apt in a different way: not returning to infancy, but having the freedom and experience to begin something new.

The Longevity Calendar

Kanreki is just the first in a series of Japanese age celebrations, each with its own name and meaning:

Age	Name	Meaning
60	還暦 (kanreki)	Return of the calendar
70	古希 (koki)	Rare since ancient times
77	喜寿 (kiju)	Joy and celebration
80	傘寿 (sanju)	Umbrella year
88	米寿 (beiju)	Rice year
90	卒寿 (sotsuju)	Graduation year
99	白寿 (hakuju)	White longevity
100	百寿 (hyakuju)	Century celebration

Each milestone builds on the last, a kind of curriculum for growing old with intention and community recognition.

Beginning Again

Standing at this threshold, I find myself thinking less about what I've accumulated and more about what comes next. The zodiac has reset. The calendar has returned to its starting point. The Fire Horse rides again.

There's something clarifying about that image—the idea that experience doesn't just pile up linearly but can circle back, offering a fresh vantage point on familiar terrain. Sixty years of context, zero years into the next cycle.

The chanchanko may be a bit theatrical for daily wear, but the idea it represents stays with me: that reaching a milestone isn't about looking backward at the distance covered, but about recognizing you're standing at a new beginning.

How do you mark significant birthdays? I'd be curious to hear about milestone traditions from other cultures.

Originally published at cogley.jp

Rick Cogley is CEO of eSolia Inc., providing bilingual IT outsourcing and infrastructure services in Tokyo, Japan.

The 72 Microseasons of Japan

Rick Cogley — Sun, 22 Mar 2026 02:11:29 +0000

Finding Poetry in Nature's Subtle Changes

In Japan, the changing seasons have always held deep cultural significance. While most of us experience a typical four seasons, traditional Japanese culture recognizes a more nuanced progression of time: the 72 microseasons (七十二候, shichijūni kō). I think it's this focus that leads to Japanese people asking visitors if they have seasons in their countries.

A Calendar of Poetic Moments

The 72 microseasons divide the year into periods of roughly five days each. Unlike the Western calendar's rigid months, these divisions mark subtle natural phenomena: Harukaze kōri o toku ("East wind melts the ice"), Sakura hajimete saku ("First cherry blossoms"), Higurashi naku ("Evening cicadas sing").

This system originated in ancient China and was adapted for Japan's climate around the 8th century AD. It's built on top of the 24 solar terms ("sekki"), which themselves divide the year into ~15-day periods aligned with the sun's position.

The Structure

Year → 4 Seasons → 24 Solar Terms → 72 Microseasons
       (3 months)    (~15 days)       (~5 days)

Each solar term contains three microseasons:

Solar Term	Meaning	Example Microseasons
立春 Risshun	Start of Spring	East wind melts ice, Warblers sing, Fish emerge
夏至 Geshi	Summer Solstice	Self-heal withers, Irises bloom, Crow-dipper sprouts
秋分 Shūbun	Autumn Equinox	Thunder ceases, Insects hole up, Farmers drain fields
冬至 Tōji	Winter Solstice	Self-heal sprouts, Deer shed antlers, Wheat sprouts under snow

Why This Matters Today

In our age of climate control and supermarket seasons, we've largely disconnected from nature's rhythms. The microseasons offer a gentle invitation to pay attention again:

Notice the small things: The first hint of plum blossoms, the return of swallows, the way morning dew appears differently through the year.
Embrace impermanence: Each microseason lasts only five days. Like everything beautiful, it passes. This echoes the Buddhist concept of mujō (無常).
Live seasonally: Traditional Japanese cuisine (washoku) emphasizes seasonal ingredients. The microseasons provide a framework for eating with nature's rhythm.

The Microseasons in Practice

On this site, you'll see a microseason card in the sidebar showing the current period along with its poetic Japanese name. It's a small reminder that time moves not just in hours and days, but in the blooming of peonies and the flight of geese.

Some favorites throughout the year:

Spring

櫻始開 (Sakura hajimete saku) — First cherry blossoms (Mar 26-30)
虹始見 (Niji hajimete arawaru) — First rainbows (Apr 15-19)

Summer

腐草為螢 (Kusaretaru kusa hotaru to naru) — Rotting grass becomes fireflies (Jun 11-15)
蓮始開 (Hasu hajimete hiraku) — First lotus blossoms (Jul 12-16)

Autumn

菊花開 (Kiku no hana hiraku) — Chrysanthemums bloom (Oct 13-17)
楓蔦黄 (Momiji tsuta kibamu) — Maple leaves turn yellow (Nov 2-6)

Winter

熊蟄穴 (Kuma ana ni komoru) — Bears retreat to their dens (Dec 12-16)
雪下出麦 (Yuki watarite mugi nobiru) — Wheat sprouts under snow (Jan 1-4)

DEV Community: Rick Cogley

Engineering Backpressure: Keeping AI-Generated Code Honest Across 10 SvelteKit Repos

The Principle

Three Linting Passes

Tracking Upstream

Centralize, Then Distribute

What It Catches

Takeaways

Learn the Hard Way First: Why New Developers Should Build Skills Before Leaning on AI

Garbage In, Garbage Out

The "It Works" Trap

What "The Hard Way" Means

A Practical Ramp

The Multiplier Effect

Audit Your SvelteKit Codebase with a JSON Feed of 34 Svelte 5 Patterns

The Problem with Static Migration Guides

Why a JSON Feed, Not a Custom Format

The Patterns Data Structure

Two Feeds, Two Audiences

The Feed Extension

The Patterns Page

What's Covered

Using It with an AI Assistant

Real-World Results

Fixes Applied Immediately

What Was Already Modern

The Greenfield Case: Mame

The Nexus Case

Future Opportunities

Implementation Notes

Feed Endpoints

Version Filtering

Feed Autodiscovery

Bilingual Support

Layout and Navigation

How This Fits Together

Related

This builds on the original migration guide article and the WebMCP tools implementation. The patterns feed complements WebMCP — WebMCP is for browser-based AI agents interacting with the page, while the JSON Feed is for CLI tools and coding assistants that can fetch URLs directly.

Cloudflare Dynamic Workers: Sandboxed Code Execution at the Edge

The Problem Before Dynamic Workers

How They Work

How I'm Using Them: Auto-Post RSS Feed Templates

The Flow

The Template

The Security Model

Cost

Another Use Case: Live Code Migration

Where They Don't Fit

What's Next

Who Moved My Settings? Automating Vendor Doc Drift Detection

The Problem: Documentation Drift

The Architecture: A Three-Gate Pipeline

Gate 1: RSS Check (Free, Milliseconds)

Gate 2: Content Hash (Cheap, Seconds)

Gate 3: AI Drift Analysis (API Cost, Seconds)

Why a Companion Worker?

Dealing with a Flaky API

What Drift Detection Looks Like

Cost

What's Next

Key Takeaways

Enabling WebMCP Tools on my SvelteKit Migration Reference

What WebMCP Is

The App

Loading Strategy

Designing the Tools

search_mappings

get_svelte_equivalent

list_ecosystem_gaps

The Other Three

The Registration Module

Testing

Updating llms.txt

Update: Svelte 4 → 5 Upgrade Data

What It Cost

The migration data was already structured and queryable. Now — with four frameworks and 120+ mappings including the Svelte 4 → 5 upgrade path — the site has an interface that AI agents can use without scraping.

Markdown for Agents on SvelteKit + Cloudflare Workers

The Problem with Transform Rules on Workers

Architecture

Detection