uniweb 1.21.3 → 1.21.5

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "uniweb",
-  "version": "1.21.3",
+  "version": "1.21.5",
   "description": "Create structured Vite + React sites with content/code separation",
   "type": "module",
   "bin": {
@@ -41,15 +41,15 @@
     "js-yaml": "^4.3.2",
     "prompts": "^2.4.2",
     "tar": "^7.5.21",
-    "@uniweb/semantic-parser": "~1.13.0",
-    "@uniweb/core": "~1.4.7",
     "@uniweb/content-writer": "~1.3.1",
-    "@uniweb/schemas": "~1.6.5"
+    "@uniweb/schemas": "~1.6.5",
+    "@uniweb/semantic-parser": "~1.13.0",
+    "@uniweb/core": "~1.4.7"
   },
   "peerDependencies": {
+    "@uniweb/build": "~1.10.5",
     "@uniweb/semantic-parser": "~1.13.0",
-    "@uniweb/content-reader": "~1.5.7",
-    "@uniweb/build": "~1.10.4"
+    "@uniweb/content-reader": "~1.5.7"
   },
   "peerDependenciesMeta": {
     "@uniweb/build": {

package/partials/agents.md

@@ -67,7 +67,7 @@ https://uniweb.io/llms.txt
 
 It lists every documentation page with a one-line description and a fetchable link. Go there whenever your question isn't answered in this file — and *especially* when you don't know whether a feature exists at all. That's where guessing does the most damage: **a 404 on a path you invented tells you your guess was wrong, not that the feature is missing.** Concluding "the framework doesn't support X" from a failed fetch is a mistake worth actively guarding against; the index answers the existence question directly.
 
-Then **follow the link the index gives you** rather than constructing one yourself. The index is the source of truth for where pages live, so it stays correct when the site's URL conventions change. (Pages also serve markdown to any client that sends `Accept: text/markdown`.)
+Then **follow the link the index gives you** rather than constructing one yourself. The index is the source of truth for where pages live, so it stays correct when the site's URL conventions change. Each link it gives is the page as Markdown.
 
 **Clone the repo instead** when you expect several lookups, or may lose network access later:
 
@@ -1515,6 +1515,8 @@ vars:
 
 Each color generates 11 OKLCH shades (50–950); shade 500 is your exact input. `neutral` takes a named preset rather than hex. Context override keys match token names: `section:` not `bg:`, `primary:` not `btn-primary-bg:`.
 
+**Quote a color, and any value with one inside it — here, in `site.yml`, in a section's frontmatter.** In YAML a `#` after a space starts a comment: `primary: #3b82f6` leaves `primary` empty, and `gradient: linear-gradient(165deg, #0c1226 0%, #05060f 100%)` keeps only `linear-gradient(165deg,`, which the browser drops. The YAML is valid, so nothing fails — the color is just not there. The build warns when it can tell (*is cut short*, *is empty*) and gives the quoted value to write.
+
 **How colors reach components:** your hex → 11 shades → semantic tokens → components. In light/medium, `--primary` uses shade 600, `--link` 600, `--ring` 500; in dark, `--primary` uses 500 and `--link` 400.
 
 **Buttons use shade 600 — darker than your input color.** That's an accessibility choice for contrast with white text. For brand-exact buttons:
@@ -2910,7 +2912,7 @@ A site can be in more than one place — usually while it moves from one host to
 - **Git is the reviewed, durable record** — you `pull` content back, read it with `git diff`, and commit.
 - **Authors never push or pull.** For them, content simply updates, whether the change came from another author or from a developer's CLI.
 
-**Working on a site others edit — run `uniweb status` when you begin, when you come back to it, before you push, publish or deploy, and after any refusal.** It reads the backend without taking anything: what changed there since this copy last synced, file by file — as `uniweb pull` would write it, translations and records included; what you hold that it lacks; where the site is live, and what services it has; who has it open in the app right now, and on which file. Then it lists the commands to run, in an order that works from the top — `uniweb pull` before the push it would otherwise refuse. Three habits go with it: take what changed (`pull`, or `refresh`) before you edit; never `--force` past a refusal; and when someone has a page open in the app, tell the person before you change that page. A step marked *ask the person first* — going live, which may cost money — is theirs to decide.
+**Working on a site others edit — run `uniweb status` when you begin, when you come back to it, before you push, publish or deploy, and after any refusal.** It reads the backend without taking anything: what changed there since this copy last synced, file by file — as `uniweb pull` would write it, translations and records included; what you hold that it lacks; where the site is live, and what services it has; who has it open in the app right now, and on which file; and what else in the project is not committed — an update, the foundation's source — which a push neither sends nor waits for, though your team builds what git holds and a push or publish releases a changed foundation from the files. Then it lists the commands to run, in an order that works from the top — `uniweb pull` before the push it would otherwise refuse. Three habits go with it: take what changed (`pull`, or `refresh`) before you edit; never `--force` past a refusal; and when someone has a page open in the app, tell the person before you change that page. A step marked *ask the person first* — a commit, sharing commits, going live, which may cost money — is theirs to decide.
 
 **Nobody's work is overwritten without asking.** `uniweb push` is refused if the site changed on the backend since your last pull — usually an author editing in the app — and reports what changed; nothing is written. Edits to different sections never collide. **In a git repository `uniweb pull` merges, like `git pull`:** it commits the backend's content (*"The site's content on …"*) and merges that commit into your branch, against the last state of the site your history shares with the backend. Your work, committed or not, and a teammate's arriving through git are kept; a file the backend never had is never deleted; changes to different parts of a file combine silently; and only a genuine overlap leaves conflict markers and a non-zero exit — so `uniweb pull && uniweb push` never ships markers. Settle a conflict as in any merge, then `git commit`; where your uncommitted changes overlap what the pull brought, the markers are theirs — settle them and `git add` each file, then `git stash drop` (git keeps them in the stash too). A push or publish is refused while a file under the site is in conflict. **In a git repository a push sends what you have committed:** with the site's content not committed it is refused before anything is sent, naming the files — commit them, or run `uniweb push --commit -m "…"` (it commits the site's content only, and leaves anything else staged as it is); `publish` and `sync` take `--commit` too. That commit is where the next pull merges from, which is how the pull tells your changes from the backend's. What the push writes back into the files — the ids the backend assigned — it commits itself, as `uniweb`. When the backend has nothing new, a pull says so and lists the files where yours hold changes it lacks. `uniweb refresh` runs `git pull` first, then the same pull. A push is also refused when your branch does not hold what this copy last took from the backend — after `git merge --abort`, or in a fresh clone that has not pulled — so pull, then push. Outside git — which includes a folder the repository around it ignores, such as a scratch directory — `uniweb pull` takes the backend's version over your files, asking first. `--force` is the deliberate overwrite (on `push` it replaces the backend's changes, on `pull` it discards yours); don't use it to get past a refusal. `uniweb sync` is `refresh` then `push`; neither publishes.
 
@@ -2965,7 +2967,7 @@ npx uniweb@latest update --dry-run   # preview exactly what update would change
 npx uniweb@latest update             # apply: align @uniweb/* deps AND refresh AGENTS.md
 ```
 
-When `status` names a newer release, take it: `npx uniweb@latest update`, then build and look at the pages. Releases rarely ask anything of a project.
+When `status` names a newer release, take it: `npx uniweb@latest update`, then build, look at the pages, and commit what the update changed — `status` lists those files until you do. Releases rarely ask anything of a project.
 
 **`npx uniweb@latest update` is the command for bringing a project up to date.** It aligns the project's `@uniweb/*` dependencies *and* this AGENTS.md to the version matrix of the CLI that runs it. Deps and documentation move together — that's the whole point of the verb.
 

package/src/commands/status.js

@@ -7,7 +7,8 @@
  * with the steps to take, in an order that works when followed from the top
  * (`utils/status-next.js`):
  *
- *   git      conflicts, a merge waiting, the site's files not committed, the git remote
+ *   git      conflicts, a merge waiting, the site's content and the project's other files
+ *            not committed, the git remote
  *   app      the session, the site, what changed on the backend since this copy last
  *            synced, what is not pushed, whether the draft is live, who has the site open,
  *            the foundation
@@ -42,8 +43,8 @@
  */
 
 import { execFileSync } from 'node:child_process'
-import { existsSync, readFileSync } from 'node:fs'
-import { basename, join, relative, resolve } from 'node:path'
+import { existsSync, readFileSync, statSync } from 'node:fs'
+import { basename, dirname, join, relative, resolve, sep } from 'node:path'
 import yaml from 'js-yaml'
 
 import {
@@ -80,7 +81,7 @@ import { aheadBehind, remoteMoved, upstreamOf } from '../utils/git.js'
 import { getLatestVersion, isBehind } from '../utils/update-check.js'
 import { syncedElsewhere } from '../utils/site-identity.js'
 import { DEFAULT_BACKEND_ORIGIN } from '../utils/config.js'
-import { classifyPackage, findSites, findWorkspaceRoot } from '../utils/workspace.js'
+import { classifyPackage, findSites, findWorkspaceRoot, isWorkspaceRoot } from '../utils/workspace.js'
 import { getCliVersion } from '../versions.js'
 import { planNext } from '../utils/status-next.js'
 
@@ -236,6 +237,63 @@ const count = (n, one, many = `${one}s`) => `${n} ${n === 1 ? one : many}`
 
 // ─── the checks ─────────────────────────────────────────────────────────────
 
+/**
+ * The project's files that git holds changes to and that are not the site's content — a
+ * dependency update, the foundation's source, `deploy.yml`, `AGENTS.md` — relative to the
+ * site, as every file list here is. The project is the workspace the site is in, or the site
+ * without one; a folder in it that is a workspace of its own is a project of its own.
+ *
+ * ⭐ A PUSH SENDS ONLY THE CONTENT, SO NOTHING STOPS FOR THESE. A teammate builds what git
+ * holds, and a push or publish releases a changed foundation from the files as they are: left
+ * uncommitted, an update or a foundation change is in this copy only, and in a release no
+ * commit holds. ⛔ Until 2026-10-26 status said "Nothing to do" over an `uniweb update` it
+ * had not seen committed.
+ *
+ * @returns {string[]|null} null when git could not be asked
+ */
+function otherUncommitted(siteDir, repo) {
+  const root = findWorkspaceRoot(siteDir) || siteDir
+  // Only the repository's part of it: a workspace above the repository's top is read from there.
+  const scope = relative(repo.top, root).startsWith('..') ? repo.top : root
+  let out
+  try {
+    out = execFileSync('git', ['status', '--porcelain', '-z', '--untracked-files=normal', '--', scope], {
+      cwd: repo.top,
+      encoding: 'utf8',
+      stdio: ['ignore', 'pipe', 'ignore'],
+      maxBuffer: 64 * 1024 * 1024
+    })
+  } catch {
+    return null
+  }
+  const parts = out.split('\0').filter(Boolean)
+  const paths = []
+  for (let i = 0; i < parts.length; i++) {
+    paths.push(parts[i].slice(3))
+    if (/[RC]/.test(parts[i].slice(0, 2))) paths.push(parts[++i]) // a rename's source follows it
+  }
+  const content = sentRoots(siteDir).map((r) => join(siteDir, r))
+  const isContent = (abs) => content.some((r) => abs === r || abs.startsWith(r + sep))
+  const isDir = (p) => {
+    try {
+      return statSync(p).isDirectory()
+    } catch {
+      return false
+    }
+  }
+  // A folder from the file up to the project's root that is a workspace of its own.
+  const inOwnProject = (abs) => {
+    for (let d = isDir(abs) ? abs : dirname(abs); d !== scope && d.startsWith(scope + sep); d = dirname(d)) {
+      if (isWorkspaceRoot(d)) return true
+    }
+    return false
+  }
+  return [...new Set(paths)]
+    .map((p) => join(repo.top, p.replace(/\/$/, '')))
+    .filter((abs) => !isContent(abs) && !inOwnProject(abs))
+    .map((abs) => relative(siteDir, abs) || '.')
+}
+
 /**
  * Git: conflicts, a merge waiting, what is not committed, and the git remote.
  * @returns {Promise<{ checks: object[], proposals: object[], localFiles: string[]|null }>}
@@ -292,9 +350,31 @@ async function gitChecks(siteDir, { offline, origin }) {
           files: uncommitted.paths,
           blocks: ['push', 'publish']
         }
-      : { id: 'git.uncommitted', state: 'ok', summary: "The site's files are committed." }
+      : { id: 'git.uncommitted', state: 'ok', summary: "The site's content is committed." }
   )
 
+  // What else in the project is not committed — a merge holds it until its commit, and a
+  // repository with no commit yet has said so above.
+  const others = merging || !repo.head ? null : otherUncommitted(siteDir, repo)
+  if (others?.length) {
+    const n = others.length
+    const fnd = resolveLocalFoundation(siteDir, readSiteYml(siteDir))
+    const ofFoundation = fnd && others.some((f) => {
+      const abs = resolve(siteDir, f)
+      return abs === fnd.dir || abs.startsWith(fnd.dir + sep)
+    })
+    checks.push({
+      id: 'git.other',
+      state: 'attention',
+      summary: `${count(n, 'other file')} here ${n === 1 ? 'is' : 'are'} not committed — a push sends only the site's content, and your team builds what git holds.`,
+      files: others,
+      lines: ofFoundation ? ["The foundation's files are among them: when a push or publish releases it, it is built from these files as they are, so commit them first."] : []
+    })
+    proposals.push({ step: 'commit', command: null, why: `commit the ${count(n, 'other file')} here: \`git add\` ${n === 1 ? 'it' : 'them'}, then \`git commit -m "<what changed>"\``, ask: true })
+  } else if (others) {
+    checks.push({ id: 'git.other', state: 'ok', summary: 'Nothing else here is uncommitted.', quiet: true })
+  }
+
   // What this copy changed since its last sync, file by file — while its branch holds the
   // sync point that sync recorded.
   let localFiles = null

package/src/framework-index.json

@@ -1,12 +1,12 @@
 {
   "schemaVersion": 1,
-  "generatedAt": "2026-10-26T19:09:19.484Z",
+  "generatedAt": "2026-10-26T19:45:51.544Z",
   "packages": {
     "@uniweb/api": {
       "version": "1.6.4"
     },
     "@uniweb/build": {
-      "version": "1.10.4"
+      "version": "1.10.5"
     },
     "@uniweb/content-reader": {
       "version": "1.5.7"

package/src/index.js

@@ -1784,7 +1784,8 @@ where, live where, deployed where — and checks:
   project  the workspace's sites and foundations, the foundation this site is built
            with and the other sites it reaches, pages from outside the site's folder,
            the languages
-  git      conflicts, a merge waiting, the site's files not committed, the git remote
+  git      conflicts, a merge waiting, the site's content not committed, the project's
+           other files not committed (an update, the foundation's source), the git remote
   app      the session, what changed on the backend since this copy last synced —
            the files a pull would change — what is not pushed, who has the site
            open in the app, the foundation

package/src/utils/status-next.js

@@ -7,13 +7,19 @@
  * then sends the reader back up. So the order is one table, not each check's own idea:
  *
  *   sign in → settle conflicts → finish a merge → take what others did (refresh, or pull)
- *   → push → push to git → go live → deploy to another host → update Uniweb → read doctor's findings
+ *   → commit what else changed → push → push to git → go live → deploy to another host
+ *   → update Uniweb → read doctor's findings
+ *
+ * A commit of the project's other files needs nothing above it — refresh's `git pull` keeps
+ * uncommitted work (`--autostash`, `utils/git.js::pullRemote`) — and comes before the push,
+ * which with the publish releases a changed foundation from the files as they are, and before a
+ * push to git, which shares only commits.
  *
  * Each check proposes steps by name (`step`); this sorts them, folds the ones another step
  * already does, and drops duplicates.
  */
 
-const ORDER = ['login', 'conflicts', 'merge', 'refresh', 'pull', 'push', 'gitpush', 'publish', 'deploy', 'update', 'doctor']
+const ORDER = ['login', 'conflicts', 'merge', 'refresh', 'pull', 'commit', 'push', 'gitpush', 'publish', 'deploy', 'update', 'doctor']
 
 /**
  * @param {Array<{ step: string, command: string|null, why: string, ask?: boolean }>} proposals