create-nifra 2.1.0 → 2.3.0

package/template-isr/server.ts

@@ -1,5 +1,5 @@
 /**
- * Local Bun dev server (no wrangler) — the same app with an in-memory ISR store. `bun run dev:bun`
+ * Local Bun dev server (no wrangler) - the same app with an in-memory ISR store. `bun run dev:bun`
  * after `bun run build`. Production uses Workers KV (worker.ts); the only line that changes is the
  * store. Watch the `x-nifra-isr` response header: miss → hit → stale.
  */

package/template-isr/worker.ts

@@ -1,5 +1,5 @@
 /**
- * Cloudflare Workers entry — the app, cached in Workers KV so cached pages and on-demand purges hold
+ * Cloudflare Workers entry - the app, cached in Workers KV so cached pages and on-demand purges hold
  * ACROSS instances. `ctx.waitUntil` keeps the worker alive while a stale page regenerates behind the
  * response. `bun run build` then `bunx wrangler dev` (a local KV is provided automatically).
  */
@@ -30,7 +30,7 @@ interface Env {
   readonly REVALIDATE_SECRET?: string
 }
 
-/** Minimal shape of the Workers execution context — just `waitUntil`. */
+/** Minimal shape of the Workers execution context - just `waitUntil`. */
 interface ExecutionContext {
   waitUntil(promise: Promise<unknown>): void
 }

package/template-isr/wrangler.toml

@@ -7,14 +7,14 @@ compatibility_flags = ["nodejs_compat"]
 # /assets/*. Non-asset paths fall through to the worker (SSR + ISR).
 assets = { directory = "./public" }
 
-# The ISR page cache. `wrangler dev` provides a LOCAL (miniflare) KV automatically — no Cloudflare
+# The ISR page cache. `wrangler dev` provides a LOCAL (miniflare) KV automatically - no Cloudflare
 # account needed. For `wrangler deploy`, create a namespace and paste its id:
 #   bunx wrangler kv namespace create ISR_CACHE
 [[kv_namespaces]]
 binding = "ISR_CACHE"
 id = "REPLACE_WITH_YOUR_KV_NAMESPACE_ID"
 
-# On-demand revalidation secret. DEV placeholder — set a real one for production with
+# On-demand revalidation secret. DEV placeholder - set a real one for production with
 # `bunx wrangler secret put REVALIDATE_SECRET`.
 [vars]
 REVALIDATE_SECRET = "dev-secret"

package/template-site/Dockerfile

@@ -1,5 +1,5 @@
 # nifra on Node, containerized. Build with Bun (nifra's build toolchain), then run the self-contained
-# bundle on a slim Node image — the final image carries no build tools or node_modules.
+# bundle on a slim Node image - the final image carries no build tools or node_modules.
 #   docker build -t my-nifra-app .
 #   docker run -p 3000:3000 my-nifra-app
 FROM oven/bun:1 AS build

package/template-site/README.md

@@ -1,6 +1,6 @@
 # nifra site
 
-A nifra + React SSR site — file-based routes, typed loaders/actions, hydration — that deploys to
+A nifra + React SSR site - file-based routes, typed loaders/actions, hydration - that deploys to
 **Bun, Node (Docker), Deno Deploy, Cloudflare Pages, and Vercel Edge from one source**. `app.fetch`
 is Web-standard, so only the server entry + build target differ per platform.
 
@@ -14,18 +14,18 @@ Edit `routes/index.tsx` (the landing + a live loader/action counter), add files
 (`about.tsx` → `/about`, `[id].tsx` → `:id`, nested `_layout.tsx` for sections), and put your data
 behind `backend.ts`.
 
-## Deploy — pick a target
+## Deploy - pick a target
 
 | target | build | deploy |
 | --- | --- | --- |
-| **Bun** (flagship) | `bun run build:bun` | `bun run start` (`bun dist-bun/server-bun.js`) — any host |
+| **Bun** (flagship) | `bun run build:bun` | `bun run start` (`bun dist-bun/server-bun.js`) - any host |
 | **Node** | `bun run build:node` | `docker build -t app . && docker run -p 3000:3000 app` (or `bun run start:node`) |
 | **Deno Deploy** | `bun run build:deno` | `deployctl deploy --prod --entrypoint=dist-deno/server-deno.js` (or `deno task start`) |
 | **Cloudflare Pages** | `bun run build` | `bun run deploy:cf` (`wrangler pages deploy dist`) |
 | **Vercel Edge** | `bun run build:vercel` | `bun run deploy:vercel` (`vercel deploy --prebuilt`) |
 
 The routes, `backend.ts`, and the client bundle are shared; each `build*` script swaps
-`buildServer`'s target/conditions and the server entry. nifra never enters your cloud credentials — the
+`buildServer`'s target/conditions and the server entry. nifra never enters your cloud credentials - the
 configs (`Dockerfile`, `deno.json`, `wrangler.toml`, Vercel Build Output API) are scaffolded; you run
 the vendor CLI.
 
@@ -33,8 +33,8 @@ the vendor CLI.
 
 ```
 routes/        index.tsx (landing), _layout.tsx (chrome), _404.tsx
-framework.ts   the render adapter (imported by the server entries — kept edge-bundlable)
-nifra.config.ts the nifra CLI's dev/build config (adapter + clientModule + Vite plugin) — read by `nifra dev`
+framework.ts   the render adapter (imported by the server entries - kept edge-bundlable)
+nifra.config.ts the nifra CLI's dev/build config (adapter + clientModule + Vite plugin) - read by `nifra dev`
 backend.ts     your contract (loaders/actions call it in-process)
 server-bun.ts  Bun entry (Bun.serve)         build-bun.ts    → dist-bun/
 _worker.ts     Cloudflare Pages entry        build.ts        → dist/

package/template-site/backend.ts

@@ -1,15 +1,13 @@
 import { server } from "@nifrajs/core/server"
-import { t } from "@nifrajs/schema"
+import { counter } from "./counter"
 
-// Your backend contract — page loaders/actions call it in-process during SSR (no network). Replace
-// the demo counter with real data (KV/D1/Postgres/…); on the edge, reach bindings via `c.env`.
-let count = 0
-
-const Counter = t.object({ count: t.number() })
-
-export const backend = server()
-  .get("/count", { response: Counter }, () => ({ count }))
-  .post("/count", { response: Counter }, () => {
-    count += 1
-    return { count }
-  })
+// Your backend contract - page loaders/actions call it in-process during SSR (no network).
+// Composition only: this module merges route modules and registers none of its own.
+//
+// That is not a style preference. `nifra check` works out what a route can reach from the module that
+// REGISTERS it, following that module's imports - so a file that registers routes AND imports a
+// database gives every route in it database reach, and a GET route may not declare a domain write at
+// all. Keeping this file pure means each route's reach is its own module's, which is what lets the
+// capability declarations in `nifra.assurance.ts` stay true as the app grows. Add a feature as a
+// module, merge it here.
+export const backend = server().merge(counter)

package/template-site/counter.ts

@@ -0,0 +1,16 @@
+import { server } from "@nifrajs/core/server"
+import { t } from "@nifrajs/schema"
+
+// Replace the demo counter with real data (KV/D1/Postgres/…); on the edge, reach bindings via `c.env`.
+// Anything this module can reach becomes reach for the routes below it, so give a feature that touches
+// a database its own module rather than adding it here.
+let count = 0
+
+const Counter = t.object({ count: t.number() })
+
+export const counter = server()
+  .get("/count", { response: Counter }, () => ({ count }))
+  .post("/count", { response: Counter }, () => {
+    count += 1
+    return { count }
+  })

package/template-site/nifra.assurance.ts

@@ -0,0 +1,83 @@
+/**
+ * What this app's routes are required to PROVE, checked by `nifra assure` (and level L1 of
+ * `nifra levels`). Evidence is collected from the routes themselves - a `body` schema records
+ * `body-bounded`, an auth middleware records `authenticated` - so this file states the requirement
+ * and the framework reports whether the route actually carries it.
+ *
+ * Page routes under `routes/` are not classified here; this is the backend contract those pages call.
+ *
+ * Rules are first-match-wins, so order matters: narrow exemptions go above the general rule, and each
+ * one is named and justified. An exemption you have to write down is one a reviewer can argue with;
+ * an exemption you get by leaving the rule off is one nobody ever sees.
+ */
+import { defineAssuranceConfig, NIFRA_ASSURANCE } from "@nifrajs/core/assurance"
+import { backend } from "./backend"
+
+export default defineAssuranceConfig({
+  source: backend,
+  // What each effect IS, so the policy below can be written about a CLASS of effect rather than a list
+  // of token names: `{ access: "write", zone: "domain" }` covers `payments.charge` the day someone adds
+  // it, where a rule naming `db.write` would not.
+  capabilities: {
+    definitions: [
+      { id: "db.read", zone: "domain", access: "read" },
+      { id: "db.write", zone: "domain", access: "write" },
+    ],
+    provenance: {
+      // Reaching one of these modules means holding the capabilities beside it, and `nifra check` fails
+      // any route that can reach further than it declared - so wiring a database into a handler and
+      // forgetting to say so is a failing check rather than something review has to catch.
+      //
+      // The first two are the seam `--db` scaffolds, split by access on purpose: reach is computed per
+      // MODULE, and a GET route may not declare a domain write, so a module that can reach both has GET
+      // routes with no legal declaration. Keeping reads and writes import-disjoint - at the seam and at
+      // the route modules - is what keeps every route's declaration equal to its reach. The drivers
+      // below are the backstop for code that goes around the seam; they grant both, because an import
+      // cannot tell a read from a write.
+      imports: [
+        { specifier: "./read.ts", capabilities: ["db.read"] },
+        { specifier: "./write.ts", capabilities: ["db.write"] },
+        { specifier: "bun:sqlite", capabilities: ["db.read", "db.write"] },
+        { specifier: "node:sqlite", capabilities: ["db.read", "db.write"] },
+        { specifier: "pg", capabilities: ["db.read", "db.write"] },
+        { specifier: "postgres", capabilities: ["db.read", "db.write"] },
+        { specifier: "mysql2", capabilities: ["db.read", "db.write"] },
+        { specifier: "kysely", capabilities: ["db.read", "db.write"] },
+        { specifier: "drizzle-orm", capabilities: ["db.read", "db.write"] },
+        { specifier: "drizzle-orm/*", capabilities: ["db.read", "db.write"] },
+        { specifier: "@libsql/*", capabilities: ["db.read", "db.write"] },
+        { specifier: "@prisma/client", capabilities: ["db.read", "db.write"] },
+      ],
+      // Add a driver here to force every query through the seam, and the check will name any route that
+      // reaches around it: `{ specifier: "pg", reason: "query through db/read.ts or db/write.ts" }`.
+      forbiddenImports: [],
+    },
+  },
+  policy: {
+    rules: [
+      // The counter increments; it accepts no input at all, so there is no body to bound. Exempted by
+      // name so the general rule below stays strict for every mutation that DOES take input.
+      { name: "bodyless-mutation", match: { methods: ["POST"], paths: ["/count"] }, require: [] },
+      // Anything that writes business state must prove who asked. Matched on what the capability IS
+      // rather than on its name or its path, so a token introduced later - `payments.charge`,
+      // `orders.write` - is covered the day it is declared instead of the day someone remembers to
+      // widen this rule. A server function is a public POST endpoint like any other, so this is what
+      // stops one shipping unauthenticated.
+      {
+        name: "authenticated-write",
+        match: { access: "write", zone: "domain" },
+        require: [NIFRA_ASSURANCE.AUTHENTICATED],
+      },
+      // Anything else that changes state must validate its input at the boundary. Adding a POST
+      // without a `body` schema fails this - which is the point: the check notices, not review.
+      {
+        name: "mutation",
+        match: { methods: ["POST", "PUT", "PATCH", "DELETE"] },
+        require: [NIFRA_ASSURANCE.BODY_BOUNDED],
+      },
+      // Reads carry no requirement yet. When some become private, split this into a public rule and
+      // an authenticated one rather than weakening the whole class.
+      { name: "read", match: { methods: ["GET"] }, require: [] },
+    ],
+  },
+})

package/template-site/nifra.config.ts

@@ -1,4 +1,4 @@
-// The nifra CLI's config — read by `nifra dev|build|start`. Separate from `framework.ts` (which the
+// The nifra CLI's config - read by `nifra dev|build|start`. Separate from `framework.ts` (which the
 // edge/server entries import, so it must stay edge-bundlable): THIS file is imported only by the CLI
 // (which runs on Bun), so it's the place for dev/build tooling like the Vite plugin. React JSX is
 // Bun-native, so the only extra is the Vite plugin for dev HMR (Fast Refresh).

package/template-site/routes/index.tsx

@@ -28,7 +28,7 @@ export default function Home(props: { data: LoaderData<typeof loader> }) {
           <span className="grad">everywhere.</span>
         </h1>
         <p>
-          SSR + hydration, end-to-end types, React. One source — deploy to Cloudflare Pages, Node,
+          SSR + hydration, end-to-end types, React. One source - deploy to Cloudflare Pages, Node,
           Deno, or Vercel Edge. Edit <code>routes/index.tsx</code> to begin.
         </p>
       </section>

package/template-site/server-node.ts

@@ -14,7 +14,7 @@ const app = createWebApp({
   title: "nifra site",
 })
 
-// @nifrajs/node serves app.fetch only — so serve /assets/* (the client bundle) from disk here.
+// @nifrajs/node serves app.fetch only - so serve /assets/* (the client bundle) from disk here.
 const ASSETS = new URL("./assets/", import.meta.url)
 const TYPES: Readonly<Record<string, string>> = { js: "text/javascript", css: "text/css" }
 

package/template-site/server-vercel.ts

@@ -12,6 +12,6 @@ const app = createWebApp({
   title: "nifra site",
 })
 
-// Vercel Edge Function — Vercel serves /assets/* from its CDN, so this only SSRs page routes.
+// Vercel Edge Function - Vercel serves /assets/* from its CDN, so this only SSRs page routes.
 export const config = { runtime: "edge" }
 export default (req: Request): Response | Promise<Response> => app.fetch(req)

package/template-site-preact/README.md

@@ -1,6 +1,6 @@
 # nifra site (Preact)
 
-A nifra + **Preact** SSR site — file-based routes, typed loaders/actions, hydration — that deploys to
+A nifra + **Preact** SSR site - file-based routes, typed loaders/actions, hydration - that deploys to
 **Bun, Node (Docker), Deno Deploy, Cloudflare Pages, and Vercel Edge from one source**. `app.fetch`
 is Web-standard, so only the server entry + build target differ per platform.
 
@@ -10,30 +10,30 @@ bun run dev        # nifra dev → true-HMR dev server (Vite + nifra SSR) at htt
 bun run preview    # wrangler pages dev dist → preview the built Cloudflare bundle (run `bun run build` first)
 ```
 
-Routes are Preact function components (JSX, via `jsxImportSource: "preact"`) under `routes/` —
+Routes are Preact function components (JSX, via `jsxImportSource: "preact"`) under `routes/` -
 `index.tsx` (landing + a live loader/action counter), `_layout.tsx` (chrome), `_404.tsx`. The
 frontend adapter is one line in `framework.ts`; data lives behind `backend.ts`.
 
-## Deploy — pick a target
+## Deploy - pick a target
 
 | target | build | deploy |
 | --- | --- | --- |
-| **Bun** (flagship) | `bun run build:bun` | `bun run start` — any host |
+| **Bun** (flagship) | `bun run build:bun` | `bun run start` - any host |
 | **Node** | `bun run build:node` | `docker build -t app . && docker run -p 3000:3000 app` (or `bun run start:node`) |
 | **Deno Deploy** | `bun run build:deno` | `deployctl deploy --prod --entrypoint=dist-deno/server-deno.js` |
 | **Cloudflare Pages** | `bun run build` | `bun run deploy:cf` |
 | **Vercel Edge** | `bun run build:vercel` | `bun run deploy:vercel` |
 
 The routes, `backend.ts`, and the client bundle are shared; each `build*` script swaps `buildServer`'s
-target/conditions and the server entry. nifra never enters your cloud credentials — it scaffolds the
+target/conditions and the server entry. nifra never enters your cloud credentials - it scaffolds the
 configs (`Dockerfile`, `deno.json`, `wrangler.toml`, Vercel Build Output API); you run the vendor CLI.
 
 ## Structure
 
 ```
 routes/        index.tsx (landing), _layout.tsx (chrome), _404.tsx
-framework.ts   the adapter (preactAdapter) — imported by the server entries (edge-bundlable)
-nifra.config.ts the nifra CLI's dev/build config (adapter + clientModule + Vite plugin) — read by `nifra dev`
+framework.ts   the adapter (preactAdapter) - imported by the server entries (edge-bundlable)
+nifra.config.ts the nifra CLI's dev/build config (adapter + clientModule + Vite plugin) - read by `nifra dev`
 backend.ts     your contract (loaders/actions call it in-process)
 server-bun.ts  Bun entry (Bun.serve)         build-bun.ts    → dist-bun/
 _worker.ts     Cloudflare Pages entry        build.ts        → dist/

package/template-site-preact/nifra.config.ts

@@ -1,4 +1,4 @@
-// The nifra CLI's config — read by `nifra dev|build|start`. Separate from `framework.ts` (which the
+// The nifra CLI's config - read by `nifra dev|build|start`. Separate from `framework.ts` (which the
 // edge/server entries import, so it must stay edge-bundlable): THIS file is imported only by the CLI
 // (which runs on Bun), so it's the place for dev/build tooling like the Vite plugin. Preact JSX is
 // Bun-native, so the only extra is the Vite plugin for dev HMR (`@preact/preset-vite` = prefresh).

package/template-site-preact/routes/index.tsx

@@ -28,7 +28,7 @@ export default function Home(props: { data: LoaderData<typeof loader> }) {
           <span className="grad">everywhere.</span>
         </h1>
         <p>
-          SSR + hydration, end-to-end types, Preact. One source — deploy to Cloudflare Pages, Node,
+          SSR + hydration, end-to-end types, Preact. One source - deploy to Cloudflare Pages, Node,
           Deno, or Vercel Edge. Edit <code>routes/index.tsx</code> to begin.
         </p>
       </section>

package/template-site-solid/README.md

@@ -1,6 +1,6 @@
 # nifra site (Solid)
 
-A nifra + **Solid** SSR site — file-based routes, typed loaders/actions, hydration — that deploys to
+A nifra + **Solid** SSR site - file-based routes, typed loaders/actions, hydration - that deploys to
 **Bun, Node (Docker), Deno Deploy, Cloudflare Pages, and Vercel Edge from one source**. `app.fetch`
 is Web-standard, so only the server entry + build target differ per platform.
 
@@ -10,30 +10,30 @@ bun run dev        # nifra dev → true-HMR dev server (Vite + nifra SSR) at htt
 bun run preview    # wrangler pages dev dist → preview the built Cloudflare bundle (run `bun run build` first)
 ```
 
-Routes are Solid function components (JSX, compiled by `solidBunPlugin`) under `routes/` — `index.tsx`
+Routes are Solid function components (JSX, compiled by `solidBunPlugin`) under `routes/` - `index.tsx`
 (landing + a live loader/action counter), `_layout.tsx` (chrome), `_404.tsx`. The frontend adapter is
 one line in `framework.ts`; data lives behind `backend.ts`. Each `build*` script wires
 `solidBunPlugin("dom")` for the client and `("ssr")` + the `solid` export condition for the server.
 
-## Deploy — pick a target
+## Deploy - pick a target
 
 | target | build | deploy |
 | --- | --- | --- |
-| **Bun** (flagship) | `bun run build:bun` | `bun run start` — any host |
+| **Bun** (flagship) | `bun run build:bun` | `bun run start` - any host |
 | **Node** | `bun run build:node` | `docker build -t app . && docker run -p 3000:3000 app` (or `bun run start:node`) |
 | **Deno Deploy** | `bun run build:deno` | `deployctl deploy --prod --entrypoint=dist-deno/server-deno.js` |
 | **Cloudflare Pages** | `bun run build` | `bun run deploy:cf` |
 | **Vercel Edge** | `bun run build:vercel` | `bun run deploy:vercel` |
 
-nifra never enters your cloud credentials — it scaffolds the configs (`Dockerfile`, `deno.json`,
+nifra never enters your cloud credentials - it scaffolds the configs (`Dockerfile`, `deno.json`,
 `wrangler.toml`, Vercel Build Output API); you run the vendor CLI.
 
 ## Structure
 
 ```
 routes/        index.tsx (landing), _layout.tsx (chrome), _404.tsx
-framework.ts   the adapter (solidAdapter) — imported by the server entries (edge-bundlable)
-nifra.config.ts the nifra CLI's dev/build config (adapter + clientModule + Solid plugins) — read by `nifra dev`
+framework.ts   the adapter (solidAdapter) - imported by the server entries (edge-bundlable)
+nifra.config.ts the nifra CLI's dev/build config (adapter + clientModule + Solid plugins) - read by `nifra dev`
 backend.ts     your contract (loaders/actions call it in-process)
 server-bun.ts  Bun entry (Bun.serve)         build-bun.ts    → dist-bun/
 _worker.ts     Cloudflare Pages entry        build.ts        → dist/

package/template-site-solid/nifra.config.ts

@@ -1,5 +1,5 @@
-// The nifra CLI's config — read by `nifra dev|build|start`. It's imported ONLY by the CLI (which runs on
-// Bun), so it can eagerly import the Vite plugin + the Solid compile plugin — keeping them OUT of the
+// The nifra CLI's config - read by `nifra dev|build|start`. It's imported ONLY by the CLI (which runs on
+// Bun), so it can eagerly import the Vite plugin + the Solid compile plugin - keeping them OUT of the
 // edge worker bundle that `framework.ts` (the render-adapter source the entries import) must stay free
 // of. Solid needs the `"solid"` resolve condition (routes solid-js to its source / JSX-dev build).
 import { solidBunPlugin } from "@nifrajs/web-solid"

package/template-site-solid/routes/index.tsx

@@ -28,7 +28,7 @@ export default function Home(props: { data: LoaderData<typeof loader> }) {
           <span class="grad">everywhere.</span>
         </h1>
         <p>
-          SSR + hydration, end-to-end types, Solid. One source — deploy to Cloudflare Pages, Node,
+          SSR + hydration, end-to-end types, Solid. One source - deploy to Cloudflare Pages, Node,
           Deno, or Vercel Edge. Edit <code>routes/index.tsx</code> to begin.
         </p>
       </section>

package/template-site-svelte/README.md

@@ -1,6 +1,6 @@
 # nifra site (Svelte)
 
-A nifra + **Svelte 5** SSR site — file-based routes, typed loaders/actions, hydration — that deploys to
+A nifra + **Svelte 5** SSR site - file-based routes, typed loaders/actions, hydration - that deploys to
 **Bun, Node (Docker), Deno Deploy, Cloudflare Pages, and Vercel Edge from one source**. `app.fetch`
 is Web-standard, so only the server entry + build target differ per platform.
 
@@ -10,32 +10,32 @@ bun run dev        # nifra dev → true-HMR dev server (Vite + nifra SSR) at htt
 bun run preview    # wrangler pages dev dist → preview the built Cloudflare bundle (run `bun run build` first)
 ```
 
-Routes are `.svelte` components under `routes/` — `index.svelte` (landing + a live loader/action
+Routes are `.svelte` components under `routes/` - `index.svelte` (landing + a live loader/action
 counter), `_layout.svelte` (chrome via the `children` snippet), `_404.svelte`. A route's
 `loader`/`action`/`meta` are named exports from its `<script module>` block; the page receives the
 loader output as the `data` prop (`let { data } = $props()`). The frontend adapter is one line in
 `framework.ts`; data lives behind `backend.ts`. Each `build*` script wires `svelteBunPlugin("dom")` for
 the client and `("ssr")` for the server.
 
-## Deploy — pick a target
+## Deploy - pick a target
 
 | target | build | deploy |
 | --- | --- | --- |
-| **Bun** (flagship) | `bun run build:bun` | `bun run start` — any host |
+| **Bun** (flagship) | `bun run build:bun` | `bun run start` - any host |
 | **Node** | `bun run build:node` | `docker build -t app . && docker run -p 3000:3000 app` (or `bun run start:node`) |
 | **Deno Deploy** | `bun run build:deno` | `deployctl deploy --prod --entrypoint=dist-deno/server-deno.js` |
 | **Cloudflare Pages** | `bun run build` | `bun run deploy:cf` |
 | **Vercel Edge** | `bun run build:vercel` | `bun run deploy:vercel` |
 
-nifra never enters your cloud credentials — it scaffolds the configs (`Dockerfile`, `deno.json`,
+nifra never enters your cloud credentials - it scaffolds the configs (`Dockerfile`, `deno.json`,
 `wrangler.toml`, Vercel Build Output API); you run the vendor CLI.
 
 ## Structure
 
 ```
 routes/        index.svelte (landing), _layout.svelte (chrome), _404.svelte
-framework.ts   the adapter (svelteAdapter) — imported by the server entries (edge-bundlable)
-nifra.config.ts the nifra CLI's dev/build config (adapter + clientModule + Svelte plugins) — read by `nifra dev`
+framework.ts   the adapter (svelteAdapter) - imported by the server entries (edge-bundlable)
+nifra.config.ts the nifra CLI's dev/build config (adapter + clientModule + Svelte plugins) - read by `nifra dev`
 backend.ts     your contract (loaders/actions call it in-process)
 server-bun.ts  Bun entry (Bun.serve)         build-bun.ts    → dist-bun/
 _worker.ts     Cloudflare Pages entry        build.ts        → dist/

package/template-site-svelte/nifra.config.ts

@@ -1,5 +1,5 @@
-// The nifra CLI's config — read by `nifra dev|build|start`. It's imported ONLY by the CLI (which runs on
-// Bun), so it can eagerly import the Vite plugin + the Svelte compiler — keeping them OUT of the edge
+// The nifra CLI's config - read by `nifra dev|build|start`. It's imported ONLY by the CLI (which runs on
+// Bun), so it can eagerly import the Vite plugin + the Svelte compiler - keeping them OUT of the edge
 // worker bundle that `framework.ts` (the render-adapter source the entries import) must stay free of.
 import { svelte } from "@sveltejs/vite-plugin-svelte"
 import { svelteBunPlugin } from "@nifrajs/web-svelte/plugin"

package/template-site-svelte/routes/_layout.svelte

@@ -1,4 +1,4 @@
-<!-- Root layout — wraps every page via the `children` snippet (the Chain fold passes the page there). -->
+<!-- Root layout - wraps every page via the `children` snippet (the Chain fold passes the page there). -->
 <script lang="ts">
   let { children } = $props()
   const css = `

package/template-site-svelte/routes/index.svelte

@@ -27,7 +27,7 @@ export async function action({ api }: ActionArgs<typeof backend>) {
 <section class="hero">
   <h1>Your nifra app,<br /><span class="grad">everywhere.</span></h1>
   <p>
-    SSR + hydration, end-to-end types, Svelte. One source — deploy to Cloudflare Pages, Node, Deno,
+    SSR + hydration, end-to-end types, Svelte. One source - deploy to Cloudflare Pages, Node, Deno,
     or Vercel Edge. Edit <code>routes/index.svelte</code> to begin.
   </p>
 </section>

package/template-site-vue/README.md

@@ -1,6 +1,6 @@
 # nifra site (Vue)
 
-A nifra + **Vue** SSR site — file-based routes, typed loaders/actions, hydration — that deploys to
+A nifra + **Vue** SSR site - file-based routes, typed loaders/actions, hydration - that deploys to
 **Bun, Node (Docker), Deno Deploy, Cloudflare Pages, and Vercel Edge from one source**. `app.fetch`
 is Web-standard, so only the server entry + build target differ per platform.
 
@@ -10,32 +10,32 @@ bun run dev        # nifra dev → true-HMR dev server (Vite + nifra SSR) at htt
 bun run preview    # wrangler pages dev dist → preview the built Cloudflare bundle (run `bun run build` first)
 ```
 
-Routes are **Vue SFCs** (`.vue`) under `routes/` — `index.vue` (landing + a live loader/action
+Routes are **Vue SFCs** (`.vue`) under `routes/` - `index.vue` (landing + a live loader/action
 counter), `_layout.vue` (chrome via the default slot), `_404.vue`. A route SFC's plain `<script>`
 carries nifra's `loader`/`action`/`meta`; `<script setup>` + `<template>` are the component. The
 build compiles them with `vueBunPlugin` (`@nifrajs/web-vue/plugin`). The frontend adapter is one line in
 `framework.ts`; data lives behind `backend.ts`.
 
-## Deploy — pick a target
+## Deploy - pick a target
 
 | target | build | deploy |
 | --- | --- | --- |
-| **Bun** (flagship) | `bun run build:bun` | `bun run start` — any host |
+| **Bun** (flagship) | `bun run build:bun` | `bun run start` - any host |
 | **Node** | `bun run build:node` | `docker build -t app . && docker run -p 3000:3000 app` (or `bun run start:node`) |
 | **Deno Deploy** | `bun run build:deno` | `deployctl deploy --prod --entrypoint=dist-deno/server-deno.js` |
 | **Cloudflare Pages** | `bun run build` | `bun run deploy:cf` |
 | **Vercel Edge** | `bun run build:vercel` | `bun run deploy:vercel` |
 
 The routes, `backend.ts`, and the client bundle are shared; each `build*` script swaps `buildServer`'s
-target/conditions and the server entry. nifra never enters your cloud credentials — it scaffolds the
+target/conditions and the server entry. nifra never enters your cloud credentials - it scaffolds the
 configs (`Dockerfile`, `deno.json`, `wrangler.toml`, Vercel Build Output API); you run the vendor CLI.
 
 ## Structure
 
 ```
 routes/        index.vue (landing), _layout.vue (chrome), _404.vue  (Vue SFCs)
-framework.ts   the adapter (vueAdapter) — imported by the server entries (edge-bundlable)
-nifra.config.ts the nifra CLI's dev/build config (adapter + clientModule + Vue plugins) — read by `nifra dev`
+framework.ts   the adapter (vueAdapter) - imported by the server entries (edge-bundlable)
+nifra.config.ts the nifra CLI's dev/build config (adapter + clientModule + Vue plugins) - read by `nifra dev`
 backend.ts     your contract (loaders/actions call it in-process)
 server-bun.ts  Bun entry (Bun.serve)         build-bun.ts    → dist-bun/
 _worker.ts     Cloudflare Pages entry        build.ts        → dist/

package/template-site-vue/nifra.config.ts

@@ -1,5 +1,5 @@
-// The nifra CLI's config — read by `nifra dev|build|start`. It's imported ONLY by the CLI (which runs on
-// Bun), so it can eagerly import the Vite plugin + the SFC compiler — keeping them OUT of the edge
+// The nifra CLI's config - read by `nifra dev|build|start`. It's imported ONLY by the CLI (which runs on
+// Bun), so it can eagerly import the Vite plugin + the SFC compiler - keeping them OUT of the edge
 // worker bundle that `framework.ts` (the render-adapter source the entries import) must stay free of.
 import { vueBunPlugin } from "@nifrajs/web-vue/plugin"
 import vue from "@vitejs/plugin-vue"

package/template-site-vue/routes/_layout.vue

@@ -1,6 +1,6 @@
 <!--
-  Root layout (Vue SFC) — wraps every page; the compose fold passes the page through the default slot.
-  The global stylesheet is rendered as a <style> element via <component :is="'style'"> — SFC <style>
+  Root layout (Vue SFC) - wraps every page; the compose fold passes the page through the default slot.
+  The global stylesheet is rendered as a <style> element via <component :is="'style'"> - SFC <style>
   blocks are dropped (nifra has no CSS pipeline), and a dynamic component sidesteps the template
   compiler's special-casing of a literal <style> tag. Keeps the whole template single-file.
 -->

package/template-site-vue/routes/index.vue

@@ -1,5 +1,5 @@
 <!--
-  Home route (Vue SFC). The plain <script> carries nifra's route convention — loader/action/meta are
+  Home route (Vue SFC). The plain <script> carries nifra's route convention - loader/action/meta are
   server-only named exports the client codegen tree-shakes out. <script setup> + <template> are the
   component. The form POST is the SSR action path; after a client submit the loader revalidates with
   no full reload (progressive enhancement). Compiled by @nifrajs/web-vue/plugin.
@@ -26,7 +26,7 @@ export async function action({ api }: ActionArgs<typeof backend>) {
 </script>
 
 <script setup lang="ts">
-// compose() spreads data/actionData/pending/submission as props — declare them so they aren't attrs.
+// compose() spreads data/actionData/pending/submission as props - declare them so they aren't attrs.
 defineProps(["data", "actionData", "pending", "submission"])
 </script>
 
@@ -35,7 +35,7 @@ defineProps(["data", "actionData", "pending", "submission"])
     <section class="hero">
       <h1>Your nifra app,<br /><span class="grad">everywhere.</span></h1>
       <p>
-        SSR + hydration, end-to-end types, Vue. One source — deploy to Cloudflare Pages, Node, Deno,
+        SSR + hydration, end-to-end types, Vue. One source - deploy to Cloudflare Pages, Node, Deno,
         or Vercel Edge. Edit <code>routes/index.vue</code> to begin.
       </p>
     </section>

package/template-site/build-bun.ts

@@ -1,27 +0,0 @@
-// Build for Bun (nifra's flagship runtime) → dist-bun/ (server-bun.js + client assets).
-// `bun run build:bun`. Run: `bun dist-bun/server-bun.js`.
-import { cpSync, mkdirSync, rmSync } from "node:fs"
-import { buildClient, buildServer } from "@nifrajs/web/build"
-
-const dir = import.meta.dir
-const dist = `${dir}/dist-bun`
-rmSync(dist, { recursive: true, force: true })
-mkdirSync(`${dist}/assets`, { recursive: true })
-
-const client = await buildClient({
-  routesDir: `${dir}/routes`,
-  outDir: `${dist}/assets`,
-  clientModule: "@nifrajs/web-react/client",
-  conditions: ["bun", "browser"],
-  define: { "process.env.NODE_ENV": '"production"' },
-})
-const { worker } = await buildServer({
-  routesDir: `${dir}/routes`,
-  serverEntry: `${dir}/server-bun.ts`,
-  outDir: `${dir}/.build-bun`,
-  target: "bun",
-  clientEntry: client.entry,
-})
-cpSync(worker, `${dist}/server-bun.js`)
-rmSync(`${dir}/.build-bun`, { recursive: true, force: true })
-console.log("Bun output → dist-bun (run: bun dist-bun/server-bun.js)")

package/template-site/build-deno.ts

@@ -1,25 +0,0 @@
-// Build for Deno → dist-deno/ (server-deno.js + client assets). `bun run build:deno`.
-import { cpSync, mkdirSync, rmSync } from "node:fs"
-import { buildClient, buildServer } from "@nifrajs/web/build"
-
-const dir = import.meta.dir
-const dist = `${dir}/dist-deno`
-rmSync(dist, { recursive: true, force: true })
-mkdirSync(`${dist}/assets`, { recursive: true })
-
-const client = await buildClient({
-  routesDir: `${dir}/routes`,
-  outDir: `${dist}/assets`,
-  clientModule: "@nifrajs/web-react/client",
-  conditions: ["bun", "browser"],
-  define: { "process.env.NODE_ENV": '"production"' },
-})
-const { worker } = await buildServer({
-  routesDir: `${dir}/routes`,
-  serverEntry: `${dir}/server-deno.ts`,
-  outDir: `${dir}/.build-deno`,
-  clientEntry: client.entry,
-})
-cpSync(worker, `${dist}/server-deno.js`)
-rmSync(`${dir}/.build-deno`, { recursive: true, force: true })
-console.log("Deno output → dist-deno (run: deno run -A dist-deno/server-deno.js)")