docs: smooth the tutorials' prose and align their style

Polish the server data inspector tutorial for natural flow (fix awkward
phrasings and grammar, normalize 'Step N — Title' headers, correct the stale
src/devframe.ts references to src/data-inspector.ts) and fix the renamed
tutorial's link in the intro. Apply the same voice and closing conventions to
the a11y tutorial.

Author: antfubot

docs/content/1.guide/1.tutorial-server-data-inspector.md

@@ -1,21 +1,19 @@
 ---
 title: 'Tutorial: Build a Server Data Inspector'
-description: 'Build a Devframe to display and query data from the server side, with a dock in a hub, a static build, a standalone server, and a CLI.'
+description: 'Build a devtool that displays and queries live server-side data, then ship it as a hub dock, a static build, a standalone server, and a CLI.'
 ---
 
-Let's build a real devtool from sketch: a **Data Inspector** that shows the shape of your server's live state and lets you read any value out of it. We'll get it working first, then teach it new tricks one at a time, a dock in a hub, a static build, a standalone server, a CLI.
+Let's build a real devtool from scratch: a **Data Inspector** that shows the shape of your server's live state and lets you read any value out of it. We'll get it working first, then teach it new tricks one at a time: a dock in a hub, a static build, a standalone server, and a CLI.
 
-## The shape of a devframe app
-
-Two halves talk over a typed connection: a **server** in your Node process that exposes server functions, and a **browser** client that gets the data and renders them nicely and provides interactivity. Devframe is everything in between, the wire, the UI hosting, auth, builds, a CLI.
+You'll need [Node 24+](https://nodejs.org/) and a terminal. Every code block is complete, so you can copy them as you go.
 
-## Step 1, Define the tool
+## The shape of a devframe app
 
-Everything starts with `defineDevframe`: your tool's name, plus a `setup` where you register what it can do. 
+A devframe app is two halves talking over a typed connection: a **server** in your Node process that exposes functions, and a **browser** client that calls them and renders the results. Devframe is everything in between: the wire, the UI hosting, auth, builds, and a CLI.
 
-> You will need [Node 24+](https://nodejs.org/) for this tutorial.
+## Step 1 — Define the tool
 
-Create the project and the definition:
+Everything starts with `defineDevframe`: your tool's name, plus a `setup` where you register what it can do. Create the project and the definition:
 
 ```sh
 mkdir data-inspector && cd data-inspector
@@ -26,7 +24,8 @@ npm install devframe && npm install -D typescript
 ```ts [src/data-inspector.ts]
 import { defineDevframe } from 'devframe'
 
-// An example server-side data, whatever you want to peek at while your app runs, config, a cache, a DB handle.
+// Some example server-side data — whatever you want to peek at while your app
+// runs: config, a cache, a DB handle.
 const serverState = {
   config: { name: 'Acme', port: 3000, debug: false },
   users: [
@@ -36,7 +35,7 @@ const serverState = {
   featureFlags: { newDashboard: true, betaSearch: false },
 }
 
-// A simple query function that follows a dot-path like `users.0.name` into the state.
+// A tiny query helper that follows a dot-path like `users.0.name` into the state.
 function valueAtPath(root: unknown, path: string): unknown {
   if (!path)
     return root
@@ -85,9 +84,9 @@ export default dataInspectorFrame
 
 `ctx.rpc.register` publishes a function the browser can call: a namespaced `name`, a `type` (`query` is read-only), and a `handler` that takes the call's arguments and returns JSON. That's the whole server. ([RPC](/guide/rpc) has the other types; [Devframe Definition](/guide/devframe-definition) has every field.)
 
-## Step 2, Add a UI
+## Step 2 — Add a UI
 
-Now the browser part. We'll use React for this example, but any framework works, the only devframe-specific line is `connectDevframe`, which opens the connection home.
+Now the browser half. We'll use React here, but any framework works — the only devframe-specific line is `connectDevframe`, which opens the connection back to the server.
 
 ```sh
 npm install react react-dom @devframes/vite
@@ -166,11 +165,11 @@ export function App() {
 }
 ```
 
-`client.call(name, ...args)` reaches your handlers. (We cast `.call` to call by name; wire up a typed registry later and every call is checked end to end, see [RPC](/guide/rpc).)
+`client.call(name, ...args)` reaches your handlers. (We cast `.call` and call by name here; wire up a typed registry and every call is checked end to end — see [RPC](/guide/rpc).)
 
-## Step 3, Run it as Development
+## Step 3 — Run it in development
 
-To try the tool we just built, we can let Vite serve the UI and hand RPC traffic to devframe:
+To try what we've built, let Vite serve the UI and hand RPC traffic to devframe:
 
 ```ts [vite.client.config.ts]
 import { devframeViteBridge } from '@devframes/vite/single'
@@ -195,21 +194,21 @@ export default defineConfig({
 npx vite --config vite.client.config.ts
 ```
 
-Open the printed URL. Three keys with their types show up, and typing `config.port` or `users.0.name` and hitting **Query** prints the value. Button → `call` → your `handler` → back to the page: that's the whole app, working.
+Open the printed URL. The three keys and their types show up, and typing `config.port` or `users.0.name` and hitting **Query** prints the value. Button → `call` → your `handler` → back to the page: that's the whole app working.
 
 > [!WARNING]
-> `auth: false` trusts anything that can reach the port. We have it off to make the tutorial easier. But we strongly recommend enabling it if you are publishing it as a tool. See [Security](/guide/security).
+> `auth: false` trusts anything that can reach the port. It's off here to keep the tutorial simple — turn it on for anything you publish or expose beyond localhost. See [Security](/guide/security).
 
-Everything below reuses this exact `src/devframe.ts` and `client/`. We only change where they run.
+From here on we reuse this same `src/data-inspector.ts` and `client/` unchanged; all that changes is where they run.
 
-## Step 4, Dock it in a hub
+## Step 4 — Dock it in a hub
 
-A [hub](/guide/hub) puts many devframes behind one interface, each a **dock** you switch between, the tool's own UI in an iframe. Since our client uses a bare `connectDevframe()`, it already works anywhere; the hub just needs the built UI. Point the definition at it:
+A [hub](/guide/hub) puts many devframes behind one interface, each a **dock** you switch between — the tool's own UI in an iframe. Since our client uses a bare `connectDevframe()`, it already works anywhere; the hub just needs the built UI, so point the definition at it:
 
-```ts [src/devframe.ts]
+```ts [src/data-inspector.ts]
 import { fileURLToPath } from 'node:url'
 // …
-export default defineDevframe({
+const dataInspectorFrame = defineDevframe({
   id: 'data-inspector',
   // …
   clientAssets: fileURLToPath(new URL('../dist/client', import.meta.url)),
@@ -244,11 +243,11 @@ export default defineConfig({
 npx vite --config vite.hub.config.ts
 ```
 
-Your inspector now sits in the hub's rail as a dock. Drop more into `devframes: [...]`, your own or the [built-in plugins](/plugins), and each gets its own. (The hub prints a code to authorize on first connect.)
+Your inspector now sits in the hub's rail as a dock. Add more to `devframes: [...]` — your own or the [built-in plugins](/plugins) — and each gets its own. (The hub prints a code to authorize on first connect.)
 
-## Step 5, Build a static version
+## Step 5 — Build a static version
 
-Some tools should work with no server at all, a report you can drop on any static host. `createBuild` renders the UI and **bakes in** the results of read-only calls. Opt one in with `snapshot: true`:
+Some tools should work with no server at all — a report you can drop on any static host. `createBuild` renders the UI and **bakes in** the results of read-only calls. Opt one in with `snapshot: true`:
 
 ```ts
 ctx.rpc.register({
@@ -274,9 +273,9 @@ npx vite build          # refresh dist/client
 node scripts/build.mjs  # → dist-static/
 ```
 
-Serve `dist-static/` anywhere and the meta list renders from the baked snapshot, no Node in sight. `query` takes an argument, so it needs the live server (next), or bake specific inputs ([Client Assets](/guide/client-assets)).
+Serve `dist-static/` anywhere and the meta list renders from the baked snapshot, no Node in sight. `query` takes an argument, so it still needs the live server (next) — or you can bake specific inputs ([Client Assets](/guide/client-assets)).
 
-## Step 6, Run it standalone
+## Step 6 — Run it standalone
 
 The definition never depended on Vite. `createDevServer` runs the tool on its own, serving the UI from `clientAssets` and answering RPC live:
 
@@ -292,11 +291,11 @@ npx vite build
 node scripts/serve.mjs
 ```
 
-Same UI, same live calls, no bundler in the loop. This is what you'd drop into your own Node program.
+Same UI, same live calls, no bundler in the loop — this is what you'd drop into your own Node program.
 
-## Step 7, Give it a CLI
+## Step 7 — Give it a CLI
 
-Finally, if you want to provide a CLI for standalone use, which wraps that server in a command shell. `devframe/adapters/cac` made it easy to automatically turn a devframe into a CLI with `dev`, `build`, and `mcp` commands. For example:
+Finally, wrap that server in a command shell. `devframe/adapters/cac` turns a devframe into a CLI with `dev`, `build`, and `mcp` commands:
 
 ```js [bin.mjs]
 #!/usr/bin/env node
@@ -314,13 +313,13 @@ node bin.mjs build   # the static build from Step 5
 node bin.mjs mcp     # expose the tool to a coding agent over MCP
 ```
 
-While you can also build a CLI on your own with the functions provides above.
+You can also assemble your own CLI from the adapter functions used above.
 
-Let's all for this tutorial. If you want to see a full-featured server data inspector, we have it a as a ready-to-use [plugin](/plugins/data-inspector) that you can play with or reference to.
+That's it for this tutorial. For a full-featured version, there's a ready-to-use [Data Inspector plugin](/plugins/data-inspector) to use or read for reference.
 
 ## What's next
 
-- [RPC](/guide/rpc), `action` and `event` calls, end-to-end types, schema validation
-- [Shared State](/guide/shared-state), push live changes to the UI without polling
-- [Hub](/guide/hub), docks, commands, terminals across many tools
-- [Agent-Native](/guide/agent-native), expose your tool to coding agents over MCP
+- [RPC](/guide/rpc) — `action` and `event` calls, end-to-end types, schema validation
+- [Shared State](/guide/shared-state) — push live changes to the UI without polling
+- [Hub](/guide/hub) — docks, commands, terminals across many tools
+- [Agent-Native](/guide/agent-native) — expose your tool to coding agents over MCP

docs/content/1.guide/2.tutorial-a11y.md

@@ -7,7 +7,7 @@ Some devtools need to reach *into* the page you're inspecting — highlight an e
 
 The point isn't the a11y check — it's the wiring. You'll see the two halves of a devtool talk to each other, and how a plugin pushes notifications up to the host.
 
-You'll need **Node 20+** and a terminal. Every code block is complete.
+You'll need [Node 20+](https://nodejs.org/) and a terminal. Every code block is complete, so you can copy them as you go.
 
 ## The two halves, and why they can't just call each other
 
@@ -310,8 +310,10 @@ We duck-typed `messages` in the agent rather than importing a hub type, so the a
 - **A same-origin channel** — the panel (iframe) and agent (host page) coordinating over `BroadcastChannel`, no server involved, each doing only what its realm allows.
 - **The messages feed** — the agent pushing notifications up to the hub with `ctx.messages`.
 
+That's it for this tutorial. For a full-featured version — axe-core, per-route tracking, and message→dock navigation — there's a ready-to-use [Accessibility Inspector plugin](/plugins/a11y) to use or read for reference.
+
 ## What's next
 
 - [Client Scripts & Client Context](/guide/client-context) — the full `DockClientScriptContext`: docks, commands, renderers, `when`
 - [Hub](/guide/hub) — the messages, docks, commands, and terminals subsystems
-- [Accessibility Inspector](/plugins/a11y) — the real plugin this tutorial distills, with axe-core, route tracking, and message→dock navigation
+- [Agent-Native](/guide/agent-native) — expose your tool to coding agents over MCP

docs/content/1.guide/index.md

@@ -169,7 +169,7 @@ The CLI adapter serves the SPA at `/`; embedded in a host (`vite`, `embedded`) t
 
 ## What's next
 
-- [Tutorial: Build a Data Inspector](/guide/tutorial) — go from an empty folder to a shippable devtool, one capability at a time
+- [Tutorial: Build a Server Data Inspector](/guide/tutorial-server-data-inspector) — go from an empty folder to a shippable devtool, one capability at a time
 - [Tutorial: An Inspector That Talks to the Page](/guide/tutorial-a11y) — client scripts, host↔panel communication, and the messages feed
 - [Devframe Definition](/guide/devframe-definition) — `defineDevframe` and `DevframeNodeContext`
 - [The Standard Handler](/adapters/initiate) — mount into any host