uniweb 0.89.0 → 0.89.2

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "uniweb",
-  "version": "0.89.0",
+  "version": "0.89.2",
   "description": "Create structured Vite + React sites with content/code separation",
   "type": "module",
   "bin": {
@@ -41,17 +41,15 @@
     "js-yaml": "^4.1.0",
     "prompts": "^2.4.2",
     "tar": "^7.0.0",
-    "@uniweb/runtime": "^0.29.5",
-    "@uniweb/core": "^0.38.0",
-    "@uniweb/kit": "^0.20.0",
+    "@uniweb/semantic-parser": "^1.5.1",
     "@uniweb/content-writer": "^0.3.4",
-    "@uniweb/schemas": "^0.13.0",
-    "@uniweb/semantic-parser": "^1.5.1"
+    "@uniweb/core": "^0.38.1",
+    "@uniweb/schemas": "^0.13.0"
   },
   "peerDependencies": {
+    "@uniweb/semantic-parser": "^1.5.1",
     "@uniweb/content-reader": "^1.2.8",
-    "@uniweb/build": "^0.80.3",
-    "@uniweb/semantic-parser": "^1.5.1"
+    "@uniweb/build": "^0.80.3"
   },
   "peerDependenciesMeta": {
     "@uniweb/build": {

package/partials/agents.md

@@ -2510,8 +2510,8 @@ const sessions = entity?.hydrated?.items.filter((item) => item.section === 'sess
 section's fields (`record.brief.name`, not `record.name`), and a record carries **no
 items**. Read one entity for its items. Each item carries `section`, its section's name
 (the word a write takes), and `id`, which is what the writer takes to update, move or
-remove it. `scope: 'mine'` lists only the viewer's own records. Without it, the operator
-also gets everyone else's.
+remove it. `scope: 'mine'` lists only the viewer's own records; without it, a list also
+holds what was shared with the viewer.
 
 ⭐ **`absent` and an empty `ready` are different answers, and confusing them is the
 mistake to avoid.** `absent` = there is no live source (no `backend` service, or nobody signed
@@ -2543,10 +2543,12 @@ await writer.remove(itemId)
 
 ### ⛔ Permissions are the SERVER'S, and your UI is only a courtesy
 
-Gate your controls on what the viewer may do — `viewer.roles` (the site's operator
-holds `system_admin`), or a record's own `can_edit` from a single-entity read — but
-**never rely on that for safety**. A foundation runs with exactly the viewer's own
-authority, so hiding a button hides a button.
+Gate your controls on what the viewer may do — a record's own `can_edit` from a
+single-entity read — but **never rely on that for safety**. A foundation runs with
+exactly the viewer's own authority, so hiding a button hides a button. ⛔ **Not on
+`viewer.roles`:** a session signed in on a site holds a member's rights — the operator's
+too — so its roles never name an administrator, and a gate on `system_admin` shows the
+operator nothing.
 
 What protects content is the **entry**: a member writes their own entries and not
 another's, and the store enforces it. **Models are open** — anyone signed in may
@@ -2565,6 +2567,42 @@ sections:
 `append_only` holds against the item's own author. That is the difference between a
 permission model and a CSS one.
 
+### The Admin link
+
+```jsx
+const { adminHref } = useSession()
+{adminHref && <a href={adminHref}>Admin</a>}
+```
+
+`adminHref` is set only for a signed-in account the backend's administration admits —
+the operator, and whoever else administers it — and is `null` for everyone else. It
+takes them there already signed in. ⛔ **Navigate to it, never `fetch` it**: the answer is
+a redirect carrying a one-time credential no script on the site is to hold. It decides
+what to offer, not what is allowed — on the site the operator acts as a member.
+
+### The links the backend mails
+
+A sign-up's confirmation, a password reset and an invitation to an address with no
+account all arrive as a link to the site's root, a token in the query — `?verify=`,
+`?reset=`, `?offer=` — and the page it lands on finishes the step:
+
+```jsx
+const { step, status, result, error, confirm } = useMailedLink()
+// step: null | 'verify' | 'reset' | 'offer'     status: 'idle' | 'working' | 'done' | 'error'
+```
+
+- `verify` finishes by itself; then the member signs in.
+- `reset` waits for `confirm({ new_password })`, and the hook supplies the token. A
+  password the rule refuses is `error.extensions.reason === 'password_too_short'`, and
+  the same link works again.
+- `offer` waits for a sign-in, then claims by itself. `result` is counts,
+  `{ invitations, grants }`, never names. ⛔ `error.kind === 'absent'` means unknown,
+  revoked or already used, alike: one sentence, no cause.
+
+Render it where the root renders it — a header or a layout is on every page. ⛔ Never
+copy the token anywhere: it is a credential, it stays in the URL until the backend has
+judged it, and then the hook takes it off.
+
 ### A backend on your machine
 
 You do not need a live backend to build against one. In `site.yml`:
@@ -2586,7 +2624,9 @@ supplies on its own origin, so cookies behave exactly as they will in production
 no address of your own for it: under `services:` an address means a backend you run, and
 asks your host to leave its own off. It **enforces** who
 may edit an entry and `append_only`, so a permission you are relying on fails on your
-machine rather than in front of a user. State is in memory; restart to reset.
+machine rather than in front of a user. The mail it would send is printed in the dev
+server's terminal, its link on your site's root — follow it to try your page; seed
+`offers: [{ email }]` to try an invitation. State is in memory; restart to reset.
 
 `uniweb create my-event --template conference` is a worked example of all of this.
 

package/src/framework-index.json

@@ -1,9 +1,9 @@
 {
   "schemaVersion": 1,
-  "generatedAt": "2026-10-09T22:44:36.037Z",
+  "generatedAt": "2026-10-11T16:47:25.397Z",
   "packages": {
     "@uniweb/api": {
-      "version": "0.7.0"
+      "version": "0.9.0"
     },
     "@uniweb/build": {
       "version": "0.80.3"
@@ -15,7 +15,7 @@
       "version": "0.3.4"
     },
     "@uniweb/core": {
-      "version": "0.38.0"
+      "version": "0.38.1"
     },
     "@uniweb/frame-bridge": {
       "version": "0.3.2"
@@ -36,7 +36,7 @@
       "version": "0.7.15"
     },
     "@uniweb/runtime": {
-      "version": "0.29.5"
+      "version": "0.29.6"
     },
     "@uniweb/scene": {
       "version": "0.1.3"
@@ -54,7 +54,7 @@
       "version": "0.1.2"
     },
     "@uniweb/templates": {
-      "version": "0.18.7"
+      "version": "0.18.8"
     },
     "@uniweb/theming": {
       "version": "0.2.0"

package/src/versions.js

@@ -9,26 +9,27 @@
  *
  * ## How versions are resolved
  *
- * 1. Start from the CLI's own `package.json` dependencies. When the CLI
- *    was installed via npm, pnpm has already resolved every `workspace:*`
- *    spec into a concrete version like `^0.9.1`, so this step is
- *    usually enough.
- * 2. For any dep that is still `workspace:*` (i.e. the CLI is running
- *    *from* the pnpm workspace — local dev, sandbox script, tests), fall
- *    back to reading the real `package.json` of each sibling package
- *    under `framework/<name>/` and using `^<that version>`. This is the
- *    path that keeps local sandboxes and templates aligned with whatever
- *    was last bumped in the monorepo.
- * 3. Scan `framework/*` to catch any additional `@uniweb/*` package that
- *    wasn't explicitly listed as a CLI dep (press, loom, scholar, etc.).
- *    New packages get picked up by the scaffolder automatically.
- *
- * The previous implementation shipped a hardcoded fallback table and
- * nothing kept it in sync with reality — see the audit note in
- * `framework/CLAUDE.md` under "Publishing". Every workspace-based scaffold
- * silently pinned against years-old versions. That table is gone. If this
- * function ever fails to resolve a package, it returns `^0.0.0` rather
- * than a stale best-guess, so the breakage is loud.
+ * 1. Start from the CLI's own `package.json` dependencies. A published CLI
+ *    carries concrete ranges like `^0.9.1` there — pnpm rewrites each
+ *    `workspace:^` spec at publish.
+ * 2. For any dep that is still a `workspace:` spec (the CLI is running
+ *    *from* a workspace checkout — local dev, sandboxes, tests), read the
+ *    `package.json` of the sibling package under `framework/<name>/` and
+ *    use `^<that version>`: the range a published CLI would carry.
+ * 3. Scan `framework/*` for every other `@uniweb/*` package (press, loom,
+ *    scholar, etc.), so a new package reaches the scaffolder automatically.
+ * 4. A published CLI has no `framework/` beside it: it reads every other
+ *    package's version from its bundled `framework-index.json`, refreshed
+ *    when the CLI is published.
+ *
+ * ⭐ A version is not a reason to depend on a package. Steps 3 and 4 name
+ * every `@uniweb/*` package, so the CLI's `dependencies` list only what its
+ * code loads — each one is installed with every `npx uniweb`.
+ *
+ * The previous implementation shipped a hardcoded fallback table that
+ * nothing kept in sync, so every scaffold silently pinned years-old
+ * versions. That table is gone. A package none of these steps resolves gets
+ * the `{{version}}` helper's `^0.1.0` (templates/processor.js).
  */
 
 import { readFileSync, readdirSync, statSync } from 'node:fs'
@@ -198,16 +199,17 @@ function getFrameworkRoot() {
 
 /**
  * Read the current on-disk version of a specific `@uniweb/*` package by
- * looking up `framework/<last-segment>/package.json`. Returns the version
- * string verbatim (e.g. `0.7.11`), or null if the package isn't present
- * on disk (i.e. the CLI is running from npm, not from the workspace).
- *
- * Returns the version *exact*, not as a caret range, to match the shape
- * published-CLI direct deps take after pnpm resolves `workspace:*` at
- * publish time. Both modes converge on identical specs in
- * `getResolvedVersions()`, so `uniweb update` and the scaffolder produce
- * the same `package.json` whether the CLI ran from npm or from this
- * monorepo.
+ * looking up `framework/<last-segment>/package.json`, as a caret range
+ * (e.g. `^0.7.11`) — or null if the package isn't on disk (the CLI is
+ * running from npm, not from a workspace checkout).
+ *
+ * ⭐ A caret, because that is what a published CLI carries: pnpm rewrites
+ * its `workspace:^` deps to `^<version>` at publish. So `uniweb update` and
+ * the scaffolder write the same `package.json` whether the CLI ran from npm
+ * or from a workspace. ⛔ This returned the version exact until 2026-10-11:
+ * right while the deps were `workspace:*`, which pnpm publishes exact, and
+ * wrong once they became `workspace:^` — so a scaffold from a workspace
+ * checkout pinned `0.20.0` where a user's got `^0.20.0`.
  */
 function readWorkspaceVersion(packageName) {
   const root = getFrameworkRoot()
@@ -219,7 +221,7 @@ function readWorkspaceVersion(packageName) {
   try {
     const pkg = JSON.parse(readFileSync(pkgPath, 'utf8'))
     if (pkg.name === packageName && pkg.version) {
-      return pkg.version
+      return `^${pkg.version}`
     }
   } catch {}
   return null
@@ -310,8 +312,8 @@ function discoverWorkspacePackages() {
 
 /**
  * Resolve a single version spec to something npm can install. A concrete
- * spec like `^0.9.0` passes through untouched; `workspace:*` is replaced
- * by the on-disk version of the named package; anything still unresolved
+ * spec like `^0.9.0` passes through untouched; a `workspace:` spec becomes
+ * `^<on-disk version>` of the named package; anything still unresolved
  * returns null so the caller can fall back.
  */
 function resolveVersionSpec(spec, packageName) {
@@ -328,8 +330,8 @@ function resolveVersionSpec(spec, packageName) {
  * Priority (highest first):
  *
  *   1. A concrete version spec already in the CLI's own `package.json`
- *      (the state after an npm publish: `workspace:*` is resolved by
- *      pnpm to a real version).
+ *      (the state after an npm publish: pnpm rewrites `workspace:^` to
+ *      `^<version>`), or a `workspace:` spec read as `^<on-disk version>`.
  *   2. Live workspace walk — every `@uniweb/*` package found under
  *      `framework/*` at CLI invocation time. This is the path that
  *      matters for local dev: a freshly-added package becomes