uniweb 1.21.2 → 1.21.4

package/package.json

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

package/partials/agents.md

@@ -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 source is among them: the next push or publish releases it from these files, 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-26T17:53:53.949Z",
+  "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"
@@ -24,7 +24,7 @@
       "version": "1.0.6"
     },
     "@uniweb/kit": {
-      "version": "1.6.5"
+      "version": "1.6.6"
     },
     "@uniweb/loom": {
       "version": "1.1.2"

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