uniweb 0.48.3 → 0.48.5

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "uniweb",
-  "version": "0.48.3",
+  "version": "0.48.5",
   "description": "Create structured Vite + React sites with content/code separation",
   "type": "module",
   "bin": {
@@ -41,15 +41,15 @@
     "js-yaml": "^4.1.0",
     "prompts": "^2.4.2",
     "tar": "^7.0.0",
-    "@uniweb/core": "^0.24.3",
-    "@uniweb/semantic-parser": "^1.4.0",
-    "@uniweb/runtime": "^0.19.4",
-    "@uniweb/kit": "^0.18.1"
+    "@uniweb/runtime": "^0.19.5",
+    "@uniweb/core": "^0.24.4",
+    "@uniweb/kit": "^0.18.2",
+    "@uniweb/semantic-parser": "^1.4.0"
   },
   "peerDependencies": {
-    "@uniweb/build": "^0.44.2",
+    "@uniweb/semantic-parser": "^1.4.0",
     "@uniweb/content-reader": "^1.2.4",
-    "@uniweb/semantic-parser": "^1.4.0"
+    "@uniweb/build": "^0.44.4"
   },
   "peerDependenciesMeta": {
     "@uniweb/build": {

package/partials/agents.md

@@ -86,7 +86,7 @@ Documentation paths in this guide are given bare — `development/creating-compo
 | Theming and styling | `authoring/theming.md` |
 | Authoring collections | `authoring/collections.md` |
 | Where-object predicate format | `authoring/predicates.md` |
-| Connecting a backend / custom transports | `development/connecting-a-backend.md` |
+| Data sources / custom transports | `development/data-sources.md` |
 | Building components | `development/creating-components.md` |
 | Schemas in practice | `development/schemas-in-practice.md` |
 | Workspace layouts and their wiring | `development/project-structures.md` |
@@ -716,7 +716,7 @@ Measured on exactly that shape: **the agent corpus holds every page; the public
 - **A static host** (`uniweb export`, `deploy --host`) drops every page — they have no reader there — and you get an empty SPA shell. The build still says *"complete"*, because 0 pages is not an error: it reports `Collected 0 pages` and pre-renders none.
 - **A backend-hosted deployment that does not offer the service.** Whether an agent endpoint exists is the host's to decide, per site — it is not implied by deploying successfully.
 
-⇒ **The way to know is to ask, at render:** `resolveService(website, 'assistant')` returns a `url` only where the host declared one. On a site that is *only* knowledge there is no component to ask — so confirm with your host that the agent is enabled for that site before you build an integration against it. If you meant to build an agent endpoint and got silence, this is where to look.
+⇒ **The way to know is to ask, at render:** `isAssistantEnabled()` from `@uniweb/kit` is true only where an agent endpoint is declared. On a site that is *only* knowledge there is no component to ask — so confirm with your host that the agent is enabled for that site before you build an integration against it. If you meant to build an agent endpoint and got silence, this is where to look.
 
 ### Your site is readable by agents, automatically
 
@@ -1843,7 +1843,7 @@ fetcher:
 
 **Failures are visible, not empty:** a fetch that failed leaves its key ABSENT from `content.data` and names the message on `block.dataError[key]`; it is never delivered as `[]`, which means "no records". The page still renders — a section reads `dataError` to tell the two apart.
 
-When a plain `url:` is enough and when a transport is the answer: `development/connecting-a-backend.md`.
+When a plain `url:` is enough and when a transport is the answer: `development/data-sources.md`.
 
 Full model: `reference/data-fetching.md`. Where-object format with examples: `authoring/predicates.md`.
 
@@ -1895,16 +1895,37 @@ section type, same arrangement as `fetcher:` and `search:`.
 
 A form gets its destination from the first of these that applies:
 
-1. **`submit:` in `site.yml`** — an endpoint you name yourself.
-2. **One the host supplies** — `services.submit` in the served payload. A site
-   published to Uniweb Cloud gets submission handling from the platform, so it
-   normally needs **no `submit:` at all**.
+1. **One the host supplies** — `services.submit` in the served payload. Where the
+   host handles submissions, that is the destination and nothing in `site.yml`
+   overrides it — so a site published to Uniweb Cloud normally needs **no
+   `submit:` at all**.
+2. **`submit:` in `site.yml`** — an endpoint you name yourself, for a host that
+   does not handle submissions, or a static site.
 3. **Neither** — there is no destination, and the form says so instead of
    guessing at one.
 
 That is the general arrangement, not a forms-only one. A host declares
 everything it offers under `services`, keyed by name, and every service resolves
-by the same rule — your declaration, then the host's, then neither:
+by the same rule — the host's offer, then your declaration, then neither.
+
+⭐ **Before you render UI for a service, ask whether the site has it** — one predicate per service,
+no arguments: `isSearchEnabled()`, `isSubmitEnabled()`, `isApiEnabled()`, `isAssistantEnabled()`,
+`isTrackingEnabled()`.
+
+```jsx
+import { isSearchEnabled } from '@uniweb/kit'
+
+if (!isSearchEnabled()) return null   // false ⇒ draw nothing
+```
+
+Each answers the same question — *would UI for this service work on this site?* — and `false`
+always means the same thing: **draw nothing.** `isSearchEnabled()` is true whenever *any* provider
+answers, including the prebuilt index a static site ships, so a search box gated on it appears
+wherever search works. The hooks that draw a feature hand you the same answer as a field
+(`useSearch().isEnabled`, `useFormSubmit().canSubmit`), so a component already using one needs
+nothing extra.
+
+When you need the **address** itself, not just whether one exists, ask for it:
 
 ```jsx
 import { resolveService } from '@uniweb/kit'
@@ -1914,7 +1935,8 @@ const { url, source } = resolveService(website, 'assistant')   // or 'search', o
 
 **The name is open**: the framework ships clients for what it implements and
 resolution for anything, so a foundation can define a service the framework has
-never heard of and a host can fill it. Same escalation `fetcher.transports`
+never heard of and a host can fill it — ask for it with
+`website.isServiceEnabled('booking')`. Same escalation `fetcher.transports`
 offers for data.
 
 **Building an "Ask AI" component?** The service name is `assistant`, and a host that runs an agent for a site typically serves it at the conventional path `/_agent`. **You should never need to write that path** — ask the runtime instead:
@@ -1936,7 +1958,7 @@ if (!url) return null          // this site has no agent — render nothing, or
 
 ### Declaring what your foundation supports
 
-`resolveService` is how you ask at render time. The other direction — telling a
+The predicates above, and `resolveService`, are how you ask at render time. The other direction — telling a
 host, *before* anything renders, which services your foundation is built to use —
 is one line in the foundation's `package.json`:
 
@@ -1953,23 +1975,24 @@ against it.** A host that offers search has no way to know whether your sections
 draw a search box, so without this it either offers a site something its code
 will ignore, or withholds something it would have used.
 
-**Three states, and they are three different answers:**
+**What a host receives is one of three answers:**
 
 | | |
 |---|---|
-| the key is **absent** | *unknown* — nobody said. Not a refusal |
-| `"supports": []` | an explicit *none* — this foundation honours no host service |
-| `"supports": ["search"]` | these, and only these |
+| a list — `["search"]` | the services this foundation renders against, and only these |
+| `[]` | none — proven by the build, not assumed |
+| absent | *unknown* — the build could not tell, and nothing was declared |
 
-⛔ **Nothing is assumed on your behalf**, in either direction. An unstated set is
-never read as "all" and never as "none", so the only way a host learns your
-search box exists is that you said so.
+⭐ **The build reads the set off your code.** When the foundation is built, `supports` is derived
+from what the bundle actually reaches — `resolveService(website, 'search')`, or a predicate like
+`isSearchEnabled()` — so a foundation that never writes the key still publishes an accurate set.
+What you write in `package.json` is a **supplement**: the build publishes the union, so a
+declaration can add a service but never remove one the code reaches.
 
-**List what you actually integrate.** `uniweb doctor` warns when your source
-reaches for a service you did not list — but it reads your code with a pattern
-matcher, so it sees `resolveService(website, 'search')` and misses a service
-reached through a variable or a helper. It can tell you that you forgot one; it
-cannot promise it found them all. The declaration is yours to keep accurate.
+**Declare only what the build cannot see.** A service reached through a *computed* name —
+`resolveService(website, name)` where `name` is a variable — is invisible to it, and the build
+warns when that happens. List those. `uniweb doctor` compares what you declared with what the build
+found.
 
 ⚖️ **Baseline behaviour is not yours to declare.** Some services do something for
 a site whether or not a foundation cooperates — the runtime reports page views
@@ -2076,7 +2099,7 @@ tracking:
 ```
 
 A host may also supply one under `services.tracking`, and the usual precedence
-applies: yours wins, then the host's, then neither.
+applies: the host's, then yours, then neither.
 
 ⚠️ **The endpoint has to accept the framework's own format** — a batched
 `{ "events": [ … ] }` POST, documented in `reference/site-configuration.md`. It
@@ -2145,17 +2168,18 @@ tracking:
 ⭐ **`emit` needs no endpoint of its own.** Where a host provides one, the site
 declares only what it wants sent and the address comes from the host. The two
 are read key by key, so naming `emit` alone overrides nothing else the host
-declared. And declaring your own `endpoint:` always wins, so a site pointing at
-its own collector keeps working on any host, including none.
+declared. An `endpoint:` of your own is used wherever the host supplies no
+collector — on a host without one, and on none — and where the host supplies
+one, the host's is used.
 
-`minimal` is `page_view` alone. `standard` is the default when you supply your
-own `endpoint:`. `all` is a standing yes, so an event added in a later framework
+`minimal` is `page_view` alone. `standard` is the default when the collector is
+your own. `all` is a standing yes, so an event added in a later framework
 release is included without you changing anything — which is exactly why
 `standard` exists as well: it is a curated set that a release cannot grow behind
 your back.
 
 ⭐ **Saying nothing means two different things, and which one depends on who
-supplies the address.** A site with its own `endpoint:` gets `standard`. A site
+supplies the address.** A site sending to its own `endpoint:` gets `standard`. A site
 on a **host-supplied** collector gets **whatever that host declares it
 collects** — it has no address of its own, so the arrangement is that the host
 does analytics for it, and the set grows when the host starts collecting
@@ -2253,8 +2277,8 @@ happened into a journey.
 Everything above reaches the runtime through `@uniweb/kit` or through something
 handed to your component as a prop. That is the rule, not a stylistic preference:
 
-- ✅ `useWebsite()`, `useTracker()`, `resolveService(website, …)` — kit hooks and
-  utilities.
+- ✅ `useWebsite()`, `useTracker()`, `isSearchEnabled()` and the other service
+  predicates, `resolveService(website, …)` — kit hooks and utilities.
 - ✅ `block.track(…)`, `block.page`, `block.website` — the block **arrives in your
   props**, so calling methods on it is not reaching for a global.
 - ⛔ `globalThis.uniweb`, `window.uniweb` — never, in a foundation.
@@ -2303,10 +2327,10 @@ For cases the factory doesn't cover, write handlers directly using `Loom`, `inst
 ## Part 4b — When the site is also an app
 
 Everything above is a site: content the author writes, built into pages. Some sites
-also have **their own backend** — accounts, per-visitor data, records their members
-create and edit. That is `@uniweb/api`.
+also have **an `api` service** — accounts, per-visitor data, records their members
+create and edit. `@uniweb/api` is its client.
 
-⛔ **Only reach for this when the site actually has one.** A site with no backend is
+⛔ **Only reach for this when the site actually has one.** A site without one is
 the normal case, and a foundation that assumes one breaks on every other site it is
 used with.
 
@@ -2323,7 +2347,7 @@ import { useSession, SignedIn, SignedOut } from '@uniweb/api'
 if (!isApiEnabled()) return <StaticVersion />   // synchronous — nothing to await
 ```
 
-⛔ **When there is no backend, draw nothing** — not a disabled control, and not an
+⛔ **When the site has no `api` service, draw nothing** — not a disabled control, and not an
 explanation. Same rule as `services` in Part 4: which capabilities a site's operator
 set up is none of a visitor's business, and "sign-in unavailable" reads as breakage
 when it is simply a feature this site does not have. Render the version of your
@@ -2336,8 +2360,8 @@ const { status, records } = useRecords({ schema: '@/session' })
 ```
 
 ⭐ **`absent` and an empty `ready` are different answers, and confusing them is the
-mistake to avoid.** `absent` = there is no live source (no backend, or nobody signed
-in) → render the site's authored content. `ready` with `records: []` = the backend
+mistake to avoid.** `absent` = there is no live source (no `api` service, or nobody signed
+in) → render the site's authored content. `ready` with `records: []` = the service
 answered and there is nothing there → render your empty state. Showing "nothing yet"
 for the first tells a visitor their content is gone when it was never requested.
 

package/src/framework-index.json

@@ -1,16 +1,16 @@
 {
   "schemaVersion": 1,
-  "generatedAt": "2026-09-10T13:34:53.674Z",
+  "generatedAt": "2026-09-10T16:24:13.926Z",
   "packages": {
     "@uniweb/api": {
-      "version": "0.3.0",
+      "version": "0.3.1",
       "path": "framework/api",
       "deps": [
         "@uniweb/core"
       ]
     },
     "@uniweb/build": {
-      "version": "0.44.2",
+      "version": "0.44.4",
       "path": "framework/build",
       "deps": [
         "@uniweb/content-reader",
@@ -34,7 +34,7 @@
       "deps": []
     },
     "@uniweb/core": {
-      "version": "0.24.3",
+      "version": "0.24.4",
       "path": "framework/core",
       "deps": [
         "@uniweb/semantic-parser",
@@ -54,7 +54,7 @@
       ]
     },
     "@uniweb/kit": {
-      "version": "0.18.1",
+      "version": "0.18.2",
       "path": "framework/kit",
       "deps": [
         "@uniweb/core",
@@ -82,7 +82,7 @@
       ]
     },
     "@uniweb/runtime": {
-      "version": "0.19.4",
+      "version": "0.19.5",
       "path": "framework/runtime",
       "deps": [
         "@uniweb/core",
@@ -110,7 +110,7 @@
       "deps": []
     },
     "@uniweb/templates": {
-      "version": "0.12.2",
+      "version": "0.12.4",
       "path": "framework/templates",
       "deps": []
     },