diff --git a/blog/async-render-in-web-components.md b/blog/async-render-in-web-components.md
index 288095fe..679bdc37 100644
--- a/blog/async-render-in-web-components.md
+++ b/blog/async-render-in-web-components.md
@@ -23,7 +23,7 @@ class UserProfile extends WebComponent({ uid: String }) {
 UserProfile.register('user-profile');
 ```
 
-That is it. No effect, no loading flag, no spinner, no `this.setState`. `render()` is allowed to be `async`. Writing `await` makes the function return a promise by the normal JavaScript rule, and every render path in WebJs already awaits a promise-returning `render()` automatically. There is no flag to set. A plain synchronous `render()` stays the zero-cost default, so you only pay for async where you actually reach for it. This is issue #469 if you want to read the history.
+That is it. No effect, no loading flag, no spinner, no `this.setState`. `render()` is allowed to be `async`. Writing `await` makes the function return a promise by the normal JavaScript rule, and every render path in WebJs already awaits a promise-returning `render()` automatically. There is no flag to set. A plain synchronous `render()` stays the zero-cost default, so you only pay for async where you actually reach for it.
 
 
 # Why this is not just useEffect with nicer syntax
@@ -74,9 +74,9 @@ That co-location is the other quiet win. The fetch lives in the leaf component t
 
 Two optimizations make this cheap, and both are on by default.
 
-A display-only async component gets **elided** (#474). If a component just fetches and renders, with no click handlers, no signals, no interactivity of any kind, then its server-rendered HTML is already the complete and final output. So WebJs drops its JavaScript module from the page entirely. The data is in the HTML, the component has nothing left to do in the browser, so nothing ships. A docs page or a content card built this way costs zero client JavaScript.
+A display-only async component gets **elided**. If a component just fetches and renders, with no click handlers, no signals, no interactivity of any kind, then its server-rendered HTML is already the complete and final output. So WebJs drops its JavaScript module from the page entirely. The data is in the HTML, the component has nothing left to do in the browser, so nothing ships. A docs page or a content card built this way costs zero client JavaScript.
 
-For a component that DOES ship (because it is also interactive), **SSR action seeding** (#472) kills the redundant re-fetch. Every `'use server'` action result computed during SSR is serialized into the page. When the component hydrates in the browser, its first RPC call reads that seed instead of hitting the network. So `getUser(this.uid)` runs once, on the server, and the client reuses the result on its first render. No hydration flicker, no wasted round trip. A later re-fetch or an argument change still goes to the server as normal.
+For a component that DOES ship (because it is also interactive), **SSR action seeding** kills the redundant re-fetch. Every `'use server'` action result computed during SSR is serialized into the page. When the component hydrates in the browser, its first RPC call reads that seed instead of hitting the network. So `getUser(this.uid)` runs once, on the server, and the client reuses the result on its first render. No hydration flicker, no wasted round trip. A later re-fetch or an argument change still goes to the server as normal.
 
 
 # When to reach for something else
diff --git a/blog/bun-serve-vs-node-http.md b/blog/bun-serve-vs-node-http.md
index 6beea82b..d9f62076 100644
--- a/blog/bun-serve-vs-node-http.md
+++ b/blog/bun-serve-vs-node-http.md
@@ -49,7 +49,7 @@ That is the entire tradeoff. You give up one preload-timing feature and you get
 
 The listener choice is the headline, but a buildless server has to earn throughput in the small places too, because there is no build step ahead of time to absorb overhead. So the Bun request path got its own passes.
 
-Brotli compression on the Bun listener runs through `node:zlib` (#518), so a Bun-served response gets the same compression a Node-served one does, no native gap there. And the per-request overhead got trimmed directly (#773): one pass removed a full request-object clone that existed only to stamp the client's IP address onto every request, and another removed an extra stream hop that every compressed response was being bridged through. Neither was large alone, but they are per-request costs, so they multiply by your traffic. On the hot path, a clone you do not need and a stream hop you can collapse are exactly the kind of thing worth cutting by hand.
+Brotli compression on the Bun listener runs through `node:zlib`, so a Bun-served response gets the same compression a Node-served one does, no native gap there. And the per-request overhead got trimmed directly: one pass removed a full request-object clone that existed only to stamp the client's IP address onto every request, and another removed an extra stream hop that every compressed response was being bridged through. Neither was large alone, but they are per-request costs, so they multiply by your traffic. On the hot path, a clone you do not need and a stream hop you can collapse are exactly the kind of thing worth cutting by hand.
 
 # You pick the runtime
 
diff --git a/blog/component-suspense-streaming.md b/blog/component-suspense-streaming.md
index 3038101b..f091b83c 100644
--- a/blog/component-suspense-streaming.md
+++ b/blog/component-suspense-streaming.md
@@ -76,4 +76,4 @@ One implementation note for the curious. A streamed component that uses `static
 
 # The takeaway
 
-WebJs blocks SSR by default so your data is in the first paint, which is the right call for fast queries and keeps the page working without JavaScript. For the one slow panel that would otherwise stall the whole first byte, wrap it in `<webjs-suspense .fallback=${...}>`. The fallback flushes immediately, the slow content streams in when it resolves, multiple boundaries fetch concurrently with no server waterfall, a throwing component stays isolated, and it all works on soft navigation too. It is plain HTML streaming, no RSC and no Flight, so the browser's own parser carries it. Fast first byte for slow data, without giving up progressive enhancement. This shipped in #470 and #471.
+WebJs blocks SSR by default so your data is in the first paint, which is the right call for fast queries and keeps the page working without JavaScript. For the one slow panel that would otherwise stall the whole first byte, wrap it in `<webjs-suspense .fallback=${...}>`. The fallback flushes immediately, the slow content streams in when it resolves, multiple boundaries fetch concurrently with no server waterfall, a throwing component stays isolated, and it all works on soft navigation too. It is plain HTML streaming, no RSC and no Flight, so the browser's own parser carries it. Fast first byte for slow data, without giving up progressive enhancement.
diff --git a/blog/full-stack-type-safety-no-build.md b/blog/full-stack-type-safety-no-build.md
index eee6c82a..ad379276 100644
--- a/blog/full-stack-type-safety-no-build.md
+++ b/blog/full-stack-type-safety-no-build.md
@@ -71,7 +71,7 @@ This is why the type safety is honest and not just optimistic. The type says `Da
 
 Server actions are the headline, but the type flow reaches the routing layer as well.
 
-Run `webjs types` and the framework generates `.webjs/routes.d.ts`, an overlay with one entry per route in `app/`. It gives you a typed `Route` union (`navigate('/blog/anything')` is fine, `navigate('/nonexistent')` is a type error) plus per-route params. `webjs dev` regenerates it on startup and after each route rebuild, so the editor always has fresh route types (this is #258, WebJs's no-build answer to Next 15's `typedRoutes`, done through interface declaration-merging instead of a bundler).
+Run `webjs types` and the framework generates `.webjs/routes.d.ts`, an overlay with one entry per route in `app/`. It gives you a typed `Route` union (`navigate('/blog/anything')` is fine, `navigate('/nonexistent')` is a type error) plus per-route params. `webjs dev` regenerates it on startup and after each route rebuild, so the editor always has fresh route types (WebJs's no-build answer to Next 15's `typedRoutes`, done through interface declaration-merging instead of a bundler).
 
 Three exported helper types read that union. `PageProps<R>` types a page's `{ params, searchParams, url, actionData }`, `LayoutProps<R>` adds `children`, and `RouteHandlerContext<R>` types a `route.ts` handler's second argument. Pass the route literal and `params` narrows to the exact shape.
 
diff --git a/blog/import-only-pages-zero-js.md b/blog/import-only-pages-zero-js.md
index 20945500..36d14f52 100644
--- a/blog/import-only-pages-zero-js.md
+++ b/blog/import-only-pages-zero-js.md
@@ -23,7 +23,7 @@ So a page's own module usually has nothing to do on the client. It rendered its
 
 # What "import-only" means
 
-Here is the subtle case, and the one this post is really about. It landed in #605 and #609.
+Here is the subtle case, and the one this post is really about.
 
 A page rarely sits there doing nothing. It imports things, in particular the interactive components it wants to render: a `<theme-toggle>`, a `<comment-box>`, a `<search-bar>`. Those components DO hydrate, so their modules genuinely need to reach the browser.
 
@@ -48,10 +48,10 @@ That last one is sneaky, because a class-name helper looks innocent. But if it r
 
 The rule of thumb is short. `page.ts` and `layout.ts` should never appear in the network tab or in the boot `<script type="module">`. If one does, something in its closure is doing client-side work, and that is your signal to find the stray side effect and move it where it belongs.
 
-You do not have to squint at the network tab to figure out which one. `webjs doctor` includes a page and layout elision advisory (#646), and a later change (#666) added advisory naming of the specific reason a given page or layout ships, so the tool tells you which client side effect pinned the module to the browser.
+You do not have to squint at the network tab to figure out which one. `webjs doctor` includes a page and layout elision advisory, and it names the specific reason a given page or layout ships, so the tool tells you which client side effect pinned the module to the browser.
 
 If you ever want everything shipped, for a debugging session or because you distrust the analysis, turn elision off with `"webjs": { "elide": false }` in the config or `WEBJS_ELIDE=0` in the environment, and every module ships as written. Dropping a page module can never change your first paint anyway, because the served HTML is identical with elision on or off.
 
 # The takeaway
 
-A React page component is client JavaScript you ship and hydrate. A WebJs page is not, because pages and layouts do not hydrate at all. Their functions run only on the server, so an import-only page or layout gets dropped entirely and the boot ships just the interactive component leaves it imported (#605, #609). A page ships whole only when it does client work of its own, and `webjs doctor` names the reason when it happens (#646, #666). The self-check is a glance at the network tab: if `page.ts` or `layout.ts` is in it, something in that module is doing browser work it should not. The result is a mostly-static page that ships almost no JavaScript, with not a single boundary marked by hand.
+A React page component is client JavaScript you ship and hydrate. A WebJs page is not, because pages and layouts do not hydrate at all. Their functions run only on the server, so an import-only page or layout gets dropped entirely and the boot ships just the interactive component leaves it imported. A page ships whole only when it does client work of its own, and `webjs doctor` names the reason when it happens. The self-check is a glance at the network tab: if `page.ts` or `layout.ts` is in it, something in that module is doing browser work it should not. The result is a mostly-static page that ships almost no JavaScript, with not a single boundary marked by hand.
diff --git a/blog/native-sqlite-node-and-bun.md b/blog/native-sqlite-node-and-bun.md
index ebac4c04..a1b01834 100644
--- a/blog/native-sqlite-node-and-bun.md
+++ b/blog/native-sqlite-node-and-bun.md
@@ -9,7 +9,7 @@ author: Vivek
 
 You clone a project, run the install, and it sits there compiling C++ for a while. Then you upgrade to a new Node major and the same package refuses to load, because the binary it built last month was compiled against a different version. You reinstall, it recompiles, and you have lost twenty minutes to a database driver that never ran a single query. If you have used SQLite in Node, you have met better-sqlite3, and you have probably met this exact afternoon.
 
-WebJs used to ship better-sqlite3 too. In #670 I pulled it out entirely and switched to the SQLite the runtime already includes. On Node that is `node:sqlite`, on Bun it is `bun:sqlite`. No native addon, no compile, nothing to rebuild when Node bumps a version.
+WebJs used to ship better-sqlite3 too. I pulled it out entirely and switched to the SQLite the runtime already includes. On Node that is `node:sqlite`, on Bun it is `bun:sqlite`. No native addon, no compile, nothing to rebuild when Node bumps a version.
 
 
 # What a native addon is, and why compiling at install is fragile
@@ -64,7 +64,7 @@ Nothing in that loop compiles a binary. The migration is a SQL file, and the dri
 
 # It also works the other direction: Postgres, same code
 
-Because Drizzle is the layer you write against, the SQLite-vs-Postgres choice is one flag at scaffold time, and the schema, queries, and actions are identical across both dialects (the dialect-parity work landed in #563).
+Because Drizzle is the layer you write against, the SQLite-vs-Postgres choice is one flag at scaffold time, and the schema, queries, and actions are identical across both dialects.
 
 ```sh
 webjs create my-app --db postgres
@@ -75,11 +75,11 @@ SQLite is the default because a new app then runs with zero setup, no server to
 
 # The payoff shows up hardest in Docker
 
-The install-time compile is annoying on your laptop and genuinely expensive in a container image, where you would otherwise ship a C++ toolchain just so a database driver could build. Dropping the native addon is what let the Bun scaffold use a pure `oven/bun:1` Dockerfile (#595, #596) with no Node in it at all.
+The install-time compile is annoying on your laptop and genuinely expensive in a container image, where you would otherwise ship a C++ toolchain just so a database driver could build. Dropping the native addon is what let the Bun scaffold use a pure `oven/bun:1` Dockerfile with no Node in it at all.
 
-That only works because two things are true at once. SQLite is built into Bun, so there is nothing to compile, and `webjs db migrate` became npx-free in #570, so the migration step needs no Node either. Remove the native addon and remove the npx dependency, and the image no longer needs a Node runtime or a compiler toolchain sitting in it. It is a smaller image that builds faster and has less to go wrong.
+That only works because two things are true at once. SQLite is built into Bun, so there is nothing to compile, and `webjs db migrate` became npx-free, so the migration step needs no Node either. Remove the native addon and remove the npx dependency, and the image no longer needs a Node runtime or a compiler toolchain sitting in it. It is a smaller image that builds faster and has less to go wrong.
 
 
 # The takeaway
 
-SQLite in Node used to mean a native addon that compiled C++ at install time, with node-gyp failures, prebuilt-binary gaps, and a forced recompile on every Node major. WebJs dropped better-sqlite3 (#670) and uses the runtime's own SQLite instead, `node:sqlite` on Node 24+ and `bun:sqlite` on Bun, so there is no compile step and no binary pinned to your runtime version. Drizzle sits on top and keeps the same code across SQLite and Postgres. The lesson generalizes past this one driver. When the platform grows a capability you were pulling in a fragile dependency for, delete the dependency and use the platform.
+SQLite in Node used to mean a native addon that compiled C++ at install time, with node-gyp failures, prebuilt-binary gaps, and a forced recompile on every Node major. WebJs dropped better-sqlite3 and uses the runtime's own SQLite instead, `node:sqlite` on Node 24+ and `bun:sqlite` on Bun, so there is no compile step and no binary pinned to your runtime version. Drizzle sits on top and keeps the same code across SQLite and Postgres. The lesson generalizes past this one driver. When the platform grows a capability you were pulling in a fragile dependency for, delete the dependency and use the platform.
diff --git a/blog/nextjs-16-file-routing-parity.md b/blog/nextjs-16-file-routing-parity.md
index 9464c3f3..18af34e5 100644
--- a/blog/nextjs-16-file-routing-parity.md
+++ b/blog/nextjs-16-file-routing-parity.md
@@ -57,7 +57,7 @@ The rule of thumb is the same one that governs `notFound()` and `redirect()`. Th
 
 # not-found is now nearest-wins
 
-This is the fix that quietly matters most for a migrator (issue #848). Previously a thrown `notFound()` in WebJs always rendered the single root `not-found` page. In Next, a `not-found.tsx` is nearest-wins, so a `not-found` deep in your tree takes over for pages beneath it. WebJs now matches that.
+This is the fix that quietly matters most for a migrator. Previously a thrown `notFound()` in WebJs always rendered the single root `not-found` page. In Next, a `not-found.tsx` is nearest-wins, so a `not-found` deep in your tree takes over for pages beneath it. WebJs now matches that.
 
 ```
 app/
@@ -110,4 +110,4 @@ export function register() {
 
 # The takeaway
 
-WebJs was already file-routing compatible with Next in shape, and these four changes (all shipped in #848 and #849) close the remaining gaps a migrator actually trips on. `forbidden()` and `unauthorized()` are control-flow throws that render the nearest boundary, with honest 403 and 401 status codes and the clear rule that you throw in a render, return an `ActionResult` in an action, and return a `Response` in a route. `not-found` is nearest-wins now, so sections get their own 404s. `params` and `searchParams` read either synchronously or awaited, so your Next code just works. And `instrumentation.js` gives you the boot hook for wiring monitoring. Bring your Next.js routing habits over, and the ones that used to fall through now land.
+WebJs was already file-routing compatible with Next in shape, and these four changes close the remaining gaps a migrator actually trips on. `forbidden()` and `unauthorized()` are control-flow throws that render the nearest boundary, with honest 403 and 401 status codes and the clear rule that you throw in a render, return an `ActionResult` in an action, and return a `Response` in a route. `not-found` is nearest-wins now, so sections get their own 404s. `params` and `searchParams` read either synchronously or awaited, so your Next code just works. And `instrumentation.js` gives you the boot hook for wiring monitoring. Bring your Next.js routing habits over, and the ones that used to fall through now land.
diff --git a/blog/no-build-frontend-performance.md b/blog/no-build-frontend-performance.md
index 4aa1a0ab..5ecbcae0 100644
--- a/blog/no-build-frontend-performance.md
+++ b/blog/no-build-frontend-performance.md
@@ -21,7 +21,7 @@ So the no-build performance problem is not really "too many requests." It is "th
 
 WebJs serves an import map in the page head. Every bare specifier a module might import (`dayjs`, or `@webjsdev/core`) resolves through it to a real URL, pinned to a CDN like jspm for third-party packages. That is the Rails 7 importmap-rails posture: no bundler, direct module URLs, the browser's native loader doing the resolution.
 
-The importmap alone does not solve discovery latency, though. It tells the browser HOW to resolve `dayjs` once it sees the import, not that it WILL need `dayjs`. So the browser still discovers the dependency only when it parses the module that imports it. That was the waterfall crack in the no-build story, and closing it (#754) is what made the posture actually competitive.
+The importmap alone does not solve discovery latency, though. It tells the browser HOW to resolve `dayjs` once it sees the import, not that it WILL need `dayjs`. So the browser still discovers the dependency only when it parses the module that imports it. That was the waterfall crack in the no-build story, and closing it is what made the posture actually competitive.
 
 The fix is `<link rel="modulepreload">`. During SSR, WebJs walks the module graph from the page's actually-shipped modules, collects every vendor specifier they reach, resolves each to its importmap target, and emits a preload hint for it in the head. So the moment the browser reads the head, it starts fetching the whole reached vendor set in parallel, before it has parsed a single component. The level-by-level discovery collapses into one parallel burst. The bytes the browser needs are already in flight by the time the code that imports them runs.
 
@@ -31,7 +31,7 @@ The walk is careful about which roots it starts from. It uses the boot's shipped
 
 The second place the cost hides is the server itself. A no-build server does more per request than a static file server, because it is resolving modules, stripping TypeScript, and running SSR. If the request path is heavy, the time-to-first-byte suffers no matter how good the preloading is.
 
-WebJs runs on Node and on Bun, and the Bun listening path got a specific pass (#773) to cut per-request overhead. The Bun shell had been cloning the whole request object on every request just to stamp the client IP, and bridging every compressed response through an extra stream hop. Both were removed: the IP is stamped out of band without rebuilding the request, and a buffered response is compressed synchronously with no bridge. That is the kind of unglamorous work that a no-build framework has to do, because there is no build step absorbing the cost ahead of time. The request path IS the product, so the request path has to be lean.
+WebJs runs on Node and on Bun, and the Bun listening path got a specific pass to cut per-request overhead. The Bun shell had been cloning the whole request object on every request just to stamp the client IP, and bridging every compressed response through an extra stream hop. Both were removed: the IP is stamped out of band without rebuilding the request, and a buffered response is compressed synchronously with no bridge. That is the kind of unglamorous work that a no-build framework has to do, because there is no build step absorbing the cost ahead of time. The request path IS the product, so the request path has to be lean.
 
 # What production actually leans on
 
diff --git a/blog/node-and-bun-no-build.md b/blog/node-and-bun-no-build.md
index 8b3c5de9..56fb776c 100644
--- a/blog/node-and-bun-no-build.md
+++ b/blog/node-and-bun-no-build.md
@@ -13,7 +13,7 @@ WebJs runs on Node 24+ and on Bun, from the same source, with no build step. You
 
 The honest reason is that Bun is fast and a lot of people want to use it, and a no-build framework is exactly the kind of thing that should not care which runtime executes it. There is no bundler output that bakes in a target. The source IS the runtime. So the only thing standing between WebJs and Bun was the set of places where the framework touches a runtime API directly, and those places turned out to be worth mapping carefully.
 
-The work landed under #508. Node 24+ is the floor because that is where the built-in TypeScript stripper and a few other primitives arrived. A boot-time preflight enforces the floor and admits Bun.
+Node 24+ is the floor because that is where the built-in TypeScript stripper and a few other primitives arrived. A boot-time preflight enforces the floor and admits Bun.
 
 # The listener seam
 
@@ -59,7 +59,7 @@ A handful of tests are legitimately Node-only. They assert a `node:http` interna
 
 # What shipped around it
 
-Because the CLI's own tooling stopped needing Node anywhere in the container, the Bun scaffold ships a pure `oven/bun:1` Dockerfile (#595). The database, test, and check tooling still run on Node, but the deployed server image is Bun all the way down. `bun create webjs my-app` picks the runtime automatically, and the `--runtime bun` flag re-flavours any of the templates for Bun.
+Because the CLI's own tooling stopped needing Node anywhere in the container, the Bun scaffold ships a pure `oven/bun:1` Dockerfile. The database, test, and check tooling still run on Node, but the deployed server image is Bun all the way down. `bun create webjs my-app` picks the runtime automatically, and the `--runtime bun` flag re-flavours any of the templates for Bun.
 
 # The takeaway
 
diff --git a/blog/optimistic-ui-without-boilerplate.md b/blog/optimistic-ui-without-boilerplate.md
index 0217746b..67739270 100644
--- a/blog/optimistic-ui-without-boilerplate.md
+++ b/blog/optimistic-ui-without-boilerplate.md
@@ -120,7 +120,7 @@ await optimistic(liked, true, () => likePost(postId));
 // Stays true on success.
 ```
 
-This is the original `optimistic(signal, value, action)` from issue #246. It captures the previous value, sets the optimistic value immediately, awaits the action, and rolls back on failure. For a like button, a follow toggle, a single boolean, this is exactly the right tool. The new declarative API is for collections and complex state where a reducer makes the intent clearer.
+This is the original `optimistic(signal, value, action)`. It captures the previous value, sets the optimistic value immediately, awaits the action, and rolls back on failure. For a like button, a follow toggle, a single boolean, this is exactly the right tool. The new declarative API is for collections and complex state where a reducer makes the intent clearer.
 
 The exported `optimistic()` function dispatches between them automatically. If the first argument has `get` and `set` methods, it is the signal-based path. Otherwise it is the declarative path. Same import, two shapes.
 
diff --git a/blog/per-action-middleware.md b/blog/per-action-middleware.md
index f83c93be..b2b2dfb6 100644
--- a/blog/per-action-middleware.md
+++ b/blog/per-action-middleware.md
@@ -85,7 +85,7 @@ import * as postActions from '#modules/posts/actions/delete-post.server.ts';
 export const DELETE = route(postActions);   // its declared middleware + validate apply
 ```
 
-Passing the whole module lets the adapter read the `export const middleware` (and `export const validate`) sitting next to the action, so the guard you declared once protects the REST boundary automatically, the same way it does on the RPC one. The guard stays a property of the action, not of a single transport. If you instead import just the function (`import { deletePost }` then `route(deletePost)`), the adapter has no way to reach its sibling config, so there you pass the chain explicitly with `route(deletePost, { middleware })`. Verified by dogfooding: the module form applies the declared guards, the bare-function form runs only what you pass it.
+Passing the whole module lets the adapter read the `export const middleware` (and `export const validate`) sitting next to the action, so the guard you declared once protects the REST boundary automatically, the same way it does on the RPC one. The guard stays a property of the action, not of a single transport. If you instead import just the function (`import { deletePost }` then `route(deletePost)`), the adapter has no way to reach its sibling config, so there you pass the chain explicitly with `route(deletePost, { middleware })`.
 
 # Compose several, in order
 
diff --git a/blog/prisma-vs-drizzle-default-orm.md b/blog/prisma-vs-drizzle-default-orm.md
index 5a7f5527..78658df1 100644
--- a/blog/prisma-vs-drizzle-default-orm.md
+++ b/blog/prisma-vs-drizzle-default-orm.md
@@ -100,7 +100,7 @@ The default database is SQLite, which means a new app runs with zero setup, no s
 webjs create my-app --db postgres
 ```
 
-Here is the part that makes this a default rather than a lock-in. The schema, the queries, and the server actions are **identical across dialects** (the dialect-parity work landed in #563). You do not rewrite your data layer to move from SQLite to Postgres. The `db/columns.server.ts` helper absorbs the per-dialect differences, and the code you wrote against `db.query...` stays the same.
+Here is the part that makes this a default rather than a lock-in. The schema, the queries, and the server actions are **identical across dialects**. You do not rewrite your data layer to move from SQLite to Postgres. The `db/columns.server.ts` helper absorbs the per-dialect differences, and the code you wrote against `db.query...` stays the same.
 
 And if you would rather use Prisma, or Kysely, or write raw SQL, that door is open too. The framework's only real contract with the database is "server-only code lives in `.server.ts` files." Whatever you export a `db` client from, and however you built it, WebJs will happily run. Swap the `db/` folder for a Prisma setup, keep `prisma generate` in your own dev script, and the rest of the framework does not change. You lose the buildless purity for that one dependency, which is a trade you are allowed to make.
 
diff --git a/blog/server-actions-without-react-server-components.md b/blog/server-actions-without-react-server-components.md
index 31120240..217daa29 100644
--- a/blog/server-actions-without-react-server-components.md
+++ b/blog/server-actions-without-react-server-components.md
@@ -44,7 +44,7 @@ The client calls `await buildReport({ from, to })` and gets back a real `Date` a
 
 # Awaiting data in a leaf, without a render tree
 
-The feature people reach for RSC to get is "fetch data inside the component that needs it, on the server, without a client waterfall." WebJs gets this from `async render()` (#469):
+The feature people reach for RSC to get is "fetch data inside the component that needs it, on the server, without a client waterfall." WebJs gets this from `async render()`:
 
 ```ts
 class UserCard extends WebComponent {
@@ -63,7 +63,7 @@ The model is decoupled into three separate concerns so it stays predictable. SSR
 
 There is a subtle cost hiding in that design. If a component fetched its data on the server during SSR, and then hydrates in the browser, does it fetch again on hydration?
 
-By default, no, because of SSR action seeding (#472). Every `'use server'` action result produced during a server render is serialized into the page, keyed by the action hash, the function name, and the serialized arguments. The generated RPC stub checks that seed on its first client call and resolves synchronously from it instead of hitting the network. So `await getUser(this.id)` runs once, on the server, and the browser reuses the result on its first render. A later refetch or an argument change misses the seed (it is consume-once) and goes to the network as normal.
+By default, no, because of SSR action seeding. Every `'use server'` action result produced during a server render is serialized into the page, keyed by the action hash, the function name, and the serialized arguments. The generated RPC stub checks that seed on its first client call and resolves synchronously from it instead of hitting the network. So `await getUser(this.id)` runs once, on the server, and the browser reuses the result on its first render. A later refetch or an argument change misses the seed (it is consume-once) and goes to the network as normal.
 
 It is fail-open by construction. A seed miss is always a normal RPC call, never wrong data. And it needs no build step and no source transform: the capture is a server-side facade over the action module, so the files on disk and the source the browser sees are byte-unchanged. You get the RSC benefit of "the server already did this work, do not redo it on the client" without the protocol that RSC needs to deliver it.
 
diff --git a/blog/ship-zero-javascript-display-only-components.md b/blog/ship-zero-javascript-display-only-components.md
index 23d05f02..2a50778d 100644
--- a/blog/ship-zero-javascript-display-only-components.md
+++ b/blog/ship-zero-javascript-display-only-components.md
@@ -11,7 +11,7 @@ Write a `<price-tag>` component in webjs. It reads a number, formats it, renders
 
 It is not there. The framework served the component's HTML and then deleted its JavaScript from the page, because it could prove the component does the same thing with or without its script. The browser downloads nothing for it.
 
-This is elision, and it is the mechanism that lets a WebJs app ship only its interactive leaves instead of its whole component tree. It landed properly in #474 and I have been sharpening it since. Here is how it works.
+This is elision, and it is the mechanism that lets a WebJs app ship only its interactive leaves instead of its whole component tree. I have been sharpening it for a while. Here is how it works.
 
 # The idea
 
@@ -55,7 +55,7 @@ The first is differential verification. A test renders a page with elision on an
 
 The second is that the analyser's signal lists cannot silently fall behind the framework. A denylist is dangerous precisely because it is a maintenance burden: every time someone adds a new way for a component to be interactive, they have to teach the analyser about it, or a component using only that new mechanism gets silently over-elided. That is the one failure mode that would actually break pages.
 
-So the lists are guarded mechanically. `lifecycle-coverage.test.js` introspects the live `WebComponent` prototype and fails the build if a new public method or hook is added without being classified in the analyser. And after a recent change (#785), `sigil-coverage.test.js` does the same for the two surfaces that are not prototype methods: the template binding sigils (`@`, `.`, `?`) and the interactivity static fields. The binding sigils are single-sourced in core, and the guard asserts the analyser classifies every one of them as either a client-behaviour ship signal (like `@event`, which drops at SSR) or an SSR-safe round-trip (like `.prop` and `?bool`, which survive into the served HTML). Add a fourth sigil to the renderer without classifying it, and the build goes red before it can ship a bug.
+So the lists are guarded mechanically. `lifecycle-coverage.test.js` introspects the live `WebComponent` prototype and fails the build if a new public method or hook is added without being classified in the analyser. And more recently, `sigil-coverage.test.js` does the same for the two surfaces that are not prototype methods: the template binding sigils (`@`, `.`, `?`) and the interactivity static fields. The binding sigils are single-sourced in core, and the guard asserts the analyser classifies every one of them as either a client-behaviour ship signal (like `@event`, which drops at SSR) or an SSR-safe round-trip (like `.prop` and `?bool`, which survive into the served HTML). Add a fourth sigil to the renderer without classifying it, and the build goes red before it can ship a bug.
 
 The point is that the safety is not "we were careful." It is "the test suite refuses to let the analyser drift." Careful is not a property you can rely on across a growing codebase written partly by agents. A failing build is.
 
diff --git a/blog/ssr-action-seeding-no-refetch.md b/blog/ssr-action-seeding-no-refetch.md
index fb4a6129..a446e59d 100644
--- a/blog/ssr-action-seeding-no-refetch.md
+++ b/blog/ssr-action-seeding-no-refetch.md
@@ -9,7 +9,7 @@ author: Vivek
 
 There is a bug that almost every server-rendered app has shipped at least once, and most never fully fix. The server renders a component with real data, sends the HTML, the browser paints it, and then the component hydrates and immediately fetches the exact same data all over again. The user already had the data on screen. The server already did the query. And now the client throws a second request at the network to fetch a copy of what it is already showing. That is the double fetch, and it costs you a wasted round trip, a possible flicker when the second result swaps in, and load on a server that had no reason to answer twice.
 
-I did not want WebJs to have this problem at all, and the fix is a feature you never have to think about. It is called SSR action-result seeding, and it landed in #472 and #486.
+I did not want WebJs to have this problem at all, and the fix is a feature you never have to think about. It is called SSR action-result seeding.
 
 # The old way, in any framework
 
@@ -58,7 +58,7 @@ A few properties make it safe to leave on and forget about:
 - It is consume-once. The seed answers the first call and then it is spent. A later refetch, or a call with changed arguments, goes to the network like normal. Seeding removes the redundant hydration fetch, not real subsequent fetches.
 - It fails open. If a seed is missing for any reason, the stub degrades to a normal RPC call. A miss costs you a network request, never wrong data. There is no failure mode where a stale or mismatched seed gets served.
 
-And the way the seed is captured is worth calling out, because it is where a build-based framework would reach for a transform. WebJs captures it through a transparent server-side `'use server'` facade. There is no source transform and no build step. The file on disk is unchanged, and the source you see in the browser's network tab is unchanged. Nothing rewrites your code to inject an initial-data payload. The facade sits at the action boundary at runtime and records what SSR computed. It runs on Bun too (#529 and #534), same as on Node.
+And the way the seed is captured is worth calling out, because it is where a build-based framework would reach for a transform. WebJs captures it through a transparent server-side `'use server'` facade. There is no source transform and no build step. The file on disk is unchanged, and the source you see in the browser's network tab is unchanged. Nothing rewrites your code to inject an initial-data payload. The facade sits at the action boundary at runtime and records what SSR computed. It runs on Bun too, same as on Node.
 
 # It composes with elision
 
diff --git a/blog/streaming-server-actions-llm.md b/blog/streaming-server-actions-llm.md
index 39c0b632..e3216df5 100644
--- a/blog/streaming-server-actions-llm.md
+++ b/blog/streaming-server-actions-llm.md
@@ -11,7 +11,7 @@ You have seen the effect. You ask ChatGPT a question and the answer appears word
 
 The catch is that the streaming version usually costs you a lot of plumbing. You reach for WebSockets, or for Server-Sent Events (a one-way stream of text from server to browser), and now you are wiring up a channel, parsing frames on the client, and handling reconnects. That is a lot of ceremony for "show the text as it arrives."
 
-In WebJs you do not write any of that. A server action can return an async generator (a function that `yield`s values over time instead of returning once), and WebJs streams each yielded chunk to the caller over the single RPC response. The call site reads them with a plain `for await` loop. That is the whole feature (#489). Let me show you.
+In WebJs you do not write any of that. A server action can return an async generator (a function that `yield`s values over time instead of returning once), and WebJs streams each yielded chunk to the caller over the single RPC response. The call site reads them with a plain `for await` loop. That is the whole feature. Let me show you.
 
 # The action: yield tokens instead of returning a string
 
@@ -87,7 +87,7 @@ WebJs respects back-pressure on the stream. The generator only advances as the r
 
 The other half of streaming is stopping. A user closes the tab halfway through a long answer. You do not want the server to keep paying an LLM to generate tokens nobody will read.
 
-WebJs handles this on both sides (#492).
+WebJs handles this on both sides.
 
 On the server, an action reads the request's `AbortSignal` through `actionSignal()` from `@webjsdev/server`. That is the `signal` I passed to the OpenAI SDK above. When the client disconnects, the signal aborts, the SDK call stops, and the generator is cancelled. (Called outside an action, `actionSignal()` returns a signal that never aborts, so a plain server-to-server call is always safe.)