uniweb 0.12.42 → 0.12.43

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "uniweb",
-  "version": "0.12.42",
+  "version": "0.12.43",
   "description": "Create structured Vite + React sites with content/code separation",
   "type": "module",
   "bin": {
@@ -41,14 +41,14 @@
     "js-yaml": "^4.1.0",
     "prompts": "^2.4.2",
     "tar": "^7.0.0",
-    "@uniweb/core": "0.7.16",
-    "@uniweb/kit": "0.9.20",
-    "@uniweb/runtime": "0.8.22"
+    "@uniweb/core": "0.7.17",
+    "@uniweb/runtime": "0.8.23",
+    "@uniweb/kit": "0.9.21"
   },
   "peerDependencies": {
     "@uniweb/content-reader": "1.1.12",
-    "@uniweb/build": "0.14.24",
-    "@uniweb/semantic-parser": "1.1.17"
+    "@uniweb/semantic-parser": "1.1.17",
+    "@uniweb/build": "0.14.25"
   },
   "peerDependenciesMeta": {
     "@uniweb/build": {

package/partials/agents.md

@@ -1005,6 +1005,67 @@ contexts:
 
 > **Contrast warning:** Bright brand colors (orange, yellow, light green) at shade 500 may not meet WCAG contrast (4.5:1) with white foreground text. Test buttons for readability — if contrast is insufficient, keep the default shade 600 mapping.
 
+### Fonts
+
+Font families are a **site** setting, configured in `theme.yml` under `fonts:`. A foundation never installs a font package (no `@fontsource/*`) and never hardcodes a family in its code — if you reach for either, you're off the paved path. The framework provides three roles and wires each onto the standard elements for you:
+
+| Role | Wired onto | Typical use |
+|---|---|---|
+| `body` | `body` (all text by default) | paragraphs, UI |
+| `heading` | `h1, h2, h3` | titles |
+| `mono` | `code, pre, kbd, samp` | code, technical text |
+
+```yaml
+# site/theme.yml
+fonts:
+  body: "Inter, system-ui, sans-serif"
+  heading: "Poppins, system-ui, sans-serif"
+  mono: "'Fira Code', monospace"
+```
+
+Because the site wires the families onto real elements, **components need no font-family classes** — render semantic markup (`<H1>`, `<P>`, `<code>` from the kit) and the roles apply. This is what lets one foundation re-font per site with zero code changes.
+
+**Loading the files** — two site-side options, both config-only, neither adds a dependency:
+
+```yaml
+# Hosted (Google Fonts or any provider). The build auto-adds preconnect
+# hints and drops families no role references.
+fonts:
+  heading: "Poppins, sans-serif"
+  import:
+    - url: "https://fonts.googleapis.com/css2?family=Poppins:wght@600;700"
+
+# Self-hosted (no CDN — privacy / offline). Put the files under
+# site/public/fonts/ and declare @font-face faces; the build emits the
+# @font-face rules + preload hints, and skips any face whose family no
+# role uses.
+fonts:
+  heading: "Söhne, sans-serif"
+  faces:
+    - { family: "Söhne", src: /fonts/soehne-bold.woff2, weight: 700 }
+    - { family: "Söhne", src: /fonts/soehne-regular.woff2, weight: 400 }
+```
+
+**In a component, weight is yours; family is the site's.** Weight / size / style utilities (`font-bold`, `font-black`, `italic`, `text-xl`) are ordinary design vocabulary — use them freely. A font-**family** utility is only safe when the family behind it is site-controlled — and by default `font-sans` / `font-serif` are *not* (they resolve to Tailwind's built-in stacks; only `font-mono` tracks the site's `mono` role, by name-collision). So a bare `font-serif` in a component silently hardcodes a typeface.
+
+**A family beyond the three roles** — an editorial serif, a display face — is a **foundation var**, so the site keeps control. Name it after a Tailwind font slot (`font-serif`) and that utility resolves to it; or give it any name and reference the variable directly:
+
+```js
+// foundation src/main.js
+export const vars = {
+  'font-serif': {
+    default: "Georgia, 'Times New Roman', serif",
+    description: 'Editorial serif for pull-quotes, taglines, quotes',
+  },
+}
+```
+```jsx
+<p className="font-serif">{content.tagline}</p>   {/* now site-controlled */}
+// …or a custom-named var:  <p style={{ fontFamily: 'var(--font-display)' }}>
+```
+
+The site sets the family in `theme.yml` under `vars:` (`font-serif: "Fraunces, Georgia, serif"`) and loads it with `fonts.import` / `fonts.faces` — the file loads even though the family isn't one of the three role slots.
+
 ### Foundation variables
 
 Most customization is handled by component params. Both section components and layout components declare their own params in `meta.js` — layouts are full components with params, not just structural wrappers. A header height, for example, is typically a layout param, not a foundation var.

package/src/framework-index.json

@@ -1,9 +1,9 @@
 {
   "schemaVersion": 1,
-  "generatedAt": "2026-07-14T12:34:40.728Z",
+  "generatedAt": "2026-07-17T21:03:16.675Z",
   "packages": {
     "@uniweb/build": {
-      "version": "0.14.24",
+      "version": "0.14.25",
       "path": "framework/build",
       "deps": [
         "@uniweb/content-reader",
@@ -25,7 +25,7 @@
       "deps": []
     },
     "@uniweb/core": {
-      "version": "0.7.16",
+      "version": "0.7.17",
       "path": "framework/core",
       "deps": [
         "@uniweb/semantic-parser",
@@ -43,7 +43,7 @@
       "deps": []
     },
     "@uniweb/kit": {
-      "version": "0.9.20",
+      "version": "0.9.21",
       "path": "framework/kit",
       "deps": [
         "@uniweb/core",
@@ -61,7 +61,7 @@
       "deps": []
     },
     "@uniweb/runtime": {
-      "version": "0.8.22",
+      "version": "0.8.23",
       "path": "framework/runtime",
       "deps": [
         "@uniweb/core",
@@ -94,7 +94,7 @@
       "deps": []
     },
     "@uniweb/theming": {
-      "version": "0.1.5",
+      "version": "0.1.6",
       "path": "framework/theming",
       "deps": []
     },