docs: multiple updates

Author: sleewoo

docs/backend/building-for-production.md

@@ -16,7 +16,7 @@ pnpm build          # all source folders
 pnpm build front    # specific folder
 ```
 
-## 📦 Build Output
+## Build Output
 
 ```txt
 dist/
@@ -34,7 +34,7 @@ dist/
 
 The SSR output is only present when [SSR is enabled](/frontend/server-side-render).
 
-## 🚀 Running in Production
+## Running in Production
 
 The simplest deployment - just run the bundled server directly:
 

docs/backend/cascading-middleware.md

@@ -13,7 +13,7 @@ head:
 Place a `use.ts` file in any folder, and its middleware automatically wraps all routes
 in that folder and its subfolders - no imports or wiring required.
 
-## 🎯 How it Works
+## How it Works
 
 ```txt
 api/users/
@@ -60,7 +60,7 @@ Beside the default exported middleware, every `use.ts` exports an `ExtendT` type
 This type extends the context for all routes underneath, giving you
 automatic type safety for anything the middleware adds.
 
-## 🔗 Type-Safe Context Extension
+## Type-Safe Context Extension
 
 The whole point of cascading middleware is to avoid manual wiring.
 That applies to types too - if your auth middleware adds `user` to the context,
@@ -149,7 +149,7 @@ alongside the middleware itself.
 > };
 > ```
 
-## 💼 Common Use Cases
+## Common Use Cases
 
 ### Authentication
 
@@ -289,7 +289,7 @@ export default [
 ```
 :::
 
-## ⚠️ Parameter Availability
+## Parameter Availability
 
 Cascading middleware runs for all routes in the hierarchy, including ones that don't
 define the parameters you might expect:
@@ -304,7 +304,7 @@ api/users/
 `ctx.params.id` is undefined for `/users`. Keep cascading middleware generic -
 authentication, logging, rate limiting. Parameter-specific logic belongs in the route handler.
 
-## 🎨 Multiple Middleware + Method Filtering
+## Multiple Middleware + Method Filtering
 
 A single `use.ts` can define multiple functions, and each supports the `on` option:
 

docs/backend/context.md

@@ -12,7 +12,7 @@ head:
 `KosmoJS` extends the standard Koa/Hono context with two additions:
 a unified bodyparser API and `ctx.validated` for type-safe access to validated request data.
 
-## 🔋 Unified Bodyparser
+## Unified Bodyparser
 
 `ctx.bodyparser` works the same regardless of framework:
 
@@ -27,7 +27,7 @@ Results are cached - calling the same parser multiple times doesn't re-parse the
 In practice you rarely call this directly. Define a validation schema in your handler
 and the appropriate parser runs automatically, placing the result in `ctx.validated`.
 
-## ☔ Validated Data Access
+## Validated Data Access
 
 `ctx.validated` holds the validated, typed result for each target you defined:
 
@@ -45,7 +45,7 @@ export default defineRoute(({ POST }) => [
 ]);
 ```
 
-## 🔗 Route Parameters
+## Route Parameters
 
 Validated params are available at `ctx.validated.params`, typed according to your refinements:
 

docs/backend/development-workflow.md

@@ -13,7 +13,7 @@ Each source folder serves a specific concern - marketing site, customer app, adm
 
 Yet, development workflow is identical.
 
-## 🚀 Starting the Dev Server
+## Starting the Dev Server
 
 ```sh
 pnpm dev          # all source folders
@@ -22,14 +22,14 @@ pnpm dev front    # specific folder (front, admin, app, etc.)
 
 Default port is `4556`, configured as `devPort` in `package.json`.
 
-## 🔀 What Happens on Start
+## What Happens on Start
 
 1. `Vite` compiles `api/app.ts`
 2. Dev server starts, serving both client pages and your API routes
 3. Requests are routed between Vite and your API
 4. File watcher monitors API files for changes
 
-## ⚙️ api/dev.ts
+## api/dev.ts
 
 `api/dev.ts` exposes three hooks for customizing the dev experience.
 
@@ -101,7 +101,7 @@ export default devSetup({
 
 Without cleanup, frequent rebuilds during active development can exhaust database connections.
 
-## 👀 Inspecting Routes
+## Inspecting Routes
 
 Each route returned by `createRoutes` has a `debug` property. Enable it via `DEBUG=api`:
 

docs/backend/error-handling.md

@@ -12,7 +12,7 @@ head:
 `KosmoJS` generates `api/errors.ts` file with a working default error handler when you create a source folder.
 It's a regular file - customize it freely.
 
-## 📦 Default Error Handler
+## Default Error Handler
 
 ::: code-group
 ```ts [Koa: api/errors.ts]
@@ -76,7 +76,7 @@ export default errorHandlerFactory(
 The Koa handler is wired into global middleware at `api/use.ts` via `errorHandler` slot.
 The Hono handler is wired into `app.onError()` in the `api/app.ts`.
 
-## 🎨 Customization
+## Customization
 
 Add logging, monitoring, or structured error responses directly in `api/errors.ts`:
 
@@ -118,7 +118,7 @@ export default appFactory(({ createApp }) => {
 });
 ```
 
-## 🎯 Route-Level Overrides (Koa)
+## Route-Level Overrides (Koa)
 
 Koa supports overriding the error handler per-route or per-subtree via `errorHandler` slot:
 
@@ -156,7 +156,7 @@ export default [
 Hono has a single `app.onError()` for the entire application - branch on `ctx.req.path`
 inside the handler if you need route-specific behavior.
 
-## 🔄 Let Handlers Fail
+## Let Handlers Fail
 
 Don't wrap handler logic in try-catch. Let errors propagate to the error handler:
 
@@ -201,7 +201,7 @@ GET(async (ctx) => {
 ```
 :::
 
-## ⚡ Koa vs Hono - Key Differences
+## Koa vs Hono - Key Differences
 
 | | Koa | Hono |
 |---|---|---|

docs/backend/intro.md

@@ -18,7 +18,7 @@ head:
 Route organization, middleware patterns, and validation are identical between the two.
 The difference is the context API inside handlers - each framework has its own.
 
-## 🔧 Defining Endpoints
+## Defining Endpoints
 
 Every API route exports a `defineRoute` definition as its default export.
 The factory function receives HTTP method builders and `use` for middleware,
@@ -53,14 +53,14 @@ Available builders: `HEAD`, `OPTIONS`, `GET`, `POST`, `PUT`, `PATCH`, `DELETE`.
 This method-based routing style draws inspiration from [Sinatra](https://sinatrarb.com/) -
 the Ruby framework that pioneered it back in 2007.
 
-## 🛡️ Type Safety
+## Type Safety
 
 Parameters, payloads, and responses are all typed through `TypeScript` type arguments -
 the same definitions drive both compile-time checking and runtime validation.
 No separate schema language, no DSL switching.
 ([Details ➜ ](/backend/type-safety))
 
-## ▶️ Middleware
+## Middleware
 
 The `use` function gives you fine-grained middleware control at the route level,
 complementing global and cascading middleware.

docs/backend/middleware.md

@@ -14,7 +14,7 @@ Beyond the standard HTTP method handlers, you often need to run custom middlewar
 code that executes before your main handler to perform tasks like authentication,
 logging, or data transformation.
 
-## 🔧 Basic Usage
+## Basic Usage
 
 KosmoJS provides the `use` function for applying middleware,
 with the same API for both `Koa` and `Hono` routes.
@@ -35,7 +35,7 @@ export default defineRoute<"example">(({ GET, POST, use }) => [
 Middleware must call `next()` to pass control to the next layer.
 Skipping `next()` short-circuits the chain - useful for early rejections.
 
-## 🔄 Execution Order (Onion Model)
+## Execution Order (Onion Model)
 
 Middleware runs in definition order going in, then unwinds in reverse after the handler.
 
@@ -87,7 +87,7 @@ export default defineRoute(({ use, GET, POST }) => [
 ]);
 ```
 
-## 🎯 Method-Specific Middleware
+## Method-Specific Middleware
 
 Use the `on` option to restrict middleware to specific HTTP methods:
 
@@ -110,7 +110,7 @@ export default defineRoute<"example">(({ GET, POST, PUT, DELETE, use }) => [
 ]);
 ```
 
-## 🎛️ Slot Composition
+## Slot Composition
 
 Slots are named positions in the middleware chain. Middleware with the same slot name
 replaces earlier middleware at that position - useful for overriding global defaults per-route.

docs/backend/type-safety.md

@@ -13,7 +13,7 @@ Type safety in `KosmoJS` covers the full request-response cycle:
 path parameters, payloads, responses, and context/state properties -
 all driving both compile-time checking and runtime validation from the same type definitions.
 
-## 🔗 Typing Params
+## Typing Params
 
 Parameters are strings by default. Refine them via the second type argument to `defineRoute`
 by providing a tuple where each position maps to the corresponding parameter in the path:
@@ -51,7 +51,7 @@ defineRoute<"[id]/[action]", Params>
 Refinements also generate runtime validation - invalid params are rejected before your handler runs.
 ([Details ➜ ](/validation/params))
 
-## 🔋 Typing Payload & Response
+## Typing Payload & Response
 
 The first type argument to each method handler defines payload and response schemas:
 
@@ -75,7 +75,7 @@ export default defineRoute<"example">(({ POST }) => [
 Both payload and response are validated at runtime, not just at compile time.
 ([Details ➜ ](/validation/payload))
 
-## 📋 Typing State & Context
+## Typing State & Context
 
 `defineRoute` accepts four type arguments:
 
@@ -136,7 +136,7 @@ export default defineRoute<
 If you find yourself declaring the same properties across many routes,
 move them to the global declarations in `api/env.d.ts` instead.
 
-## ⚙️ Global Context Types - `api/env.d.ts`
+## Global Context Types - `api/env.d.ts`
 
 `api/env.d.ts` extends the default context and state interfaces globally,
 so every route handler picks them up automatically:

docs/features.md

@@ -12,15 +12,15 @@ head:
 
 Everything `KosmoJS` provides, at a glance.
 
-## 🗂️ Multiple Source Folders
+## Multiple Source Folders
 
 Organize distinct concerns - public site, customer app, admin dashboard -
 as independent source folders within a single `Vite` project.
 Each gets its own set of frameworks, base URL, development workflow and build pipeline.
 
 [Read more ➜](/start#📁-create-your-first-source-folder)
 
-## 🛣️ Directory-Based Routing
+## Directory-Based Routing
 
 Your folder structure defines your routes - for both API and client pages.
 
@@ -41,7 +41,7 @@ files/[name].[ext]/index.ts         ➜ files/document.pdf, /files/logo.png
 
 [Read more ➜](/routing/intro)
 
-## ⚡ Power Syntax for Params
+## Power Syntax for Params
 
 When standard named parameters aren't enough, use raw [path-to-regexp v8](https://github.com/pillarjs/path-to-regexp)
 patterns directly in your folder names:
@@ -58,7 +58,7 @@ without sacrificing the directory-based routing model.
 
 [Read more ➜](/routing/params#power-syntax)
 
-## 🛡️ End-to-End Type Safety
+## End-to-End Type Safety
 
 Write `TypeScript` types once - `KosmoJS` generates runtime validators automatically.
 The same definition drives compile-time checking, runtime validation, type-safe fetch clients, and OpenAPI specs.
@@ -81,7 +81,7 @@ export default defineRoute(({ POST }) => [
 
 [Read more ➜](/validation/intro)
 
-## 🔗 Generated Fetch Clients + OpenAPI
+## Generated Fetch Clients + OpenAPI
 
 For every API route, `KosmoJS` generates a fully-typed fetch client
 and an OpenAPI 3.1 spec - both derived from the same type definitions.
@@ -95,7 +95,7 @@ const user = await fetchClients["users/[id]"].GET([123]);
 
 [Fetch Clients ➜](/fetch/intro) · [OpenAPI ➜](/openapi)
 
-## 🎛️ Composable Middleware (Slots)
+## Composable Middleware (Slots)
 
 Global middleware defined in `api/use.ts` can be overridden per-route or per-subtree
 using named slots - without removing or bypassing parent middleware entirely.
@@ -114,7 +114,7 @@ Custom slot names are supported by extending the `UseSlots` interface.
 
 [Read more ➜](/backend/middleware)
 
-## 🌊 Cascading Middleware
+## Cascading Middleware
 
 Place a `use.ts` file in any folder and its middleware automatically wraps
 all routes in that folder and its subfolders - no imports or wiring needed.
@@ -129,7 +129,7 @@ Combine with slots to override globals for entire route subtrees.
 
 [Read more ➜](/backend/cascading-middleware)
 
-## 🪆 Nested Layouts
+## Nested Layouts
 
 Frontend pages support nested layout components that wrap child routes -
 compose shared UI (nav, sidebars, auth shells) at any level of the route hierarchy.
@@ -147,7 +147,7 @@ pages/
 
 [Read more ➜](/frontend/routing)
 
-## 🎨 Multiple Frameworks
+## Multiple Frameworks
 
 **Backend:** `Koa` or `Hono` - same routing architecture, same type safety.
 **Frontend:** `React`, `Vue`, `SolidJS`, `MDX` - same routing/layout/SSR conventions.
@@ -159,7 +159,7 @@ Switch frameworks per folder without learning a new set of conventions.
 
 [Read more ➜](/frontend/intro)
 
-## 🔧 Built on Proven Tools
+## Built on Proven Tools
 
 No proprietary runtime, no custom bundler, no framework lock-in.
 Every layer is a tool you can use, debug, and replace independently.

docs/fetch/intro.md

@@ -16,7 +16,7 @@ The result is a fully-typed client that mirrors your route definition exactly.
 Parameters, payload shape, response type - all derived from the same source.
 Change your API, and the client updates with it. No manual sync required.
 
-## 🤖 What Gets Generated
+## What Gets Generated
 
 Each route's client module exports:
 
@@ -33,7 +33,7 @@ exposed for client-side form validation with `check`, `errors`, `errorMessage`,
 `errorSummary`, and `validate` methods.
 ([Details ➜ ](/fetch/validation))
 
-## 🏗️ Using the Generated Client
+## Using the Generated Client
 
 Import the fetch map and pick the client for your route by path: