@niroai/niro 0.7.0 → 0.8.0

package/CHANGELOG.md

@@ -2,6 +2,52 @@
 
 Notable changes to `@niroai/niro`. Dates are release dates.
 
+## 0.8.0 — 2026-08-26
+
+Needed before a server has the layered store turned on. On an older client the new
+server-side setting is not just unusable, it is misleading.
+
+### Upgrading
+
+```bash
+npm install -g @niroai/niro@latest
+```
+
+Nothing extra is needed from 0.7.0.
+
+### Why this release exists
+
+A working copy is a private index of the branch in your folder, including edits you have not
+committed. The server can now keep several of them per developer, and can store one as a
+layer over the shared project rather than a full copy. Three things in 0.7.0 get in the way.
+
+**A second working copy was refused on your own machine.** 0.7.0 decided by itself that one
+folder already held the project, and never asked the server. Once the server allows several,
+that refusal is simply wrong. Worse, run unattended, by an agent or a script, it threw an
+error advising `niro discard-temp-project` in the other folder. Following that advice
+destroys a working copy that did not need destroying. The client now asks the server and
+does what it says.
+
+**A git worktree of a repo with no remote could not be onboarded at all.** Niro records
+onboarding against the folder that was onboarded, which is the main checkout. A linked
+worktree has no entry of its own, so the repo could not be named and `niro new-temp-project`
+failed. It now resolves the main working tree through `git rev-parse --git-common-dir`.
+That combination, a worktree of a remote-less repo, is the layered store's main use case.
+
+**Large files were dropped from a working copy without telling you.** The size warning
+existed only in `niro init`. A developer ran `niro new-temp-project` and lost their three
+largest source files, the ones the whole branch was about. Niro then answered questions
+about those files from the shared project's older copy, confidently, with nothing on screen
+to say the working copy did not contain them. The warning now runs on both commands, and it
+quotes the limit the server reports rather than a number compiled into the client, which
+said 256 KiB while a server raised to 2 MiB was accepting the file happily.
+
+### Compatibility
+
+Against an older server, the per-file limit is not reported and the client falls back to its
+built-in figure, so the warning quotes an estimate rather than the server's real cap. Nothing
+else changes.
+
 ## 0.7.0 — 2026-08-17
 
 A data-loss release. If you use `niro watch`, upgrade.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@niroai/niro",
-  "version": "0.7.0",
+  "version": "0.8.0",
   "description": "Niro — one package: the niro CLI plus the Niro MCP server (code intelligence for AI coding assistants).",
   "keywords": [
     "niro",

package/src/commands/add-repo.js

@@ -174,6 +174,7 @@ async function addRepo(pathArg, opts = {}) {
   // Get filter recommendation
   console.log(`  Analyzing project structure...`);
   const filterResult = await agentApi.filterManifest(gitId, manifest);
+  folderSync.warnOversizeFiles(manifest, filterResult, (m) => console.log(color.yellow(m)));
   const includedCount = filterResult.included_count || filterResult.includedCount || 0;
   const excludedCount = filterResult.excluded_count || filterResult.excludedCount || 0;
 

package/src/commands/init.js

@@ -422,16 +422,9 @@ async function init(pathArg, opts = {}) {
     process.stdout.write(`\n  Scanning ${color.cyan(targetDir)}...`);
     const manifest = folderSync.buildManifest(targetDir);
     process.stdout.write(` ${manifest.length} files found.\n`);
-    for (const m of manifest) {
-      if (m.size_bytes > folderSync.PER_FILE_CAP_BYTES) {
-        console.log(warn(
-          `       ⚠ ${m.path} (${Math.round(m.size_bytes / 1024)} KiB) exceeds the ` +
-          `256 KiB per-file cap — it will be skipped and not indexed.`
-        ));
-      }
-    }
-
     const filterResult = await agentApi.filterManifest(gitId, manifest);
+    // After the filter, not before: the limit is the SERVER's, and it reports it back to us.
+    folderSync.warnOversizeFiles(manifest, filterResult, (m) => console.log(warn(m)));
     const includedPaths = filterResult.included_paths || filterResult.includedPaths || [];
     const includedCount = filterResult.included_count || filterResult.includedCount || includedPaths.length;
     const excludedCount = filterResult.excluded_count || filterResult.excludedCount || 0;

package/src/commands/takeover.js

@@ -48,7 +48,18 @@ async function takeover(pathArg, opts = {}) {
   const ctx = await resolveCtxLib.resolveContext(targetDir, { apiUrl: opts.apiUrl });
   if (ctx.state === "error") throw new Error(`Could not resolve project: ${ctx.error}`);
   if (!ctx.projects.length) {
-    throw new Error("This folder's git remote doesn't match any Niro project. Run `niro init` first.");
+    // Two different dead ends, and telling them apart is the difference between a fix and a guess.
+    // A folder with no git remote is not a broken setup: `niro init` never required one. What is
+    // missing is the LOCAL record naming the repo, and for a git worktree that record belongs to the
+    // main checkout, not to the folder you are standing in. The old message sent every such user off
+    // to add a remote, which does not help: the repo keeps the URL it was registered with.
+    if (ctx.state === "no_origin") {
+      throw new Error(
+        "This folder has no git remote, and no Niro repo is recorded for it on this machine. "
+        + "Run `niro init` here, or, if this is a git worktree, run it once in the main checkout, "
+        + "then re-run this command.");
+    }
+    throw new Error("This folder's git remote does not match any Niro project. Run `niro init` first.");
   }
   let source = ctx.projects[0];
   if (opts.project) {
@@ -83,8 +94,29 @@ async function takeover(pathArg, opts = {}) {
   // already reflecting this folder, and the branch it names has moved on. The server relabels it, which
   // is right, and a prompt there would be pure friction.
   const here = path.resolve(repoRoot);
-  const holder = watchState.allLocal(api.currentBaseUrl()).find((e) =>
+  // Matched on the REPO as well as the project, and that second clause is the whole point.
+  //
+  // The hazard this guard exists for is one REPO checked out in two folders on two branches, both
+  // uploading into one copy until every answer is a blend of the two. Matching on the project alone
+  // also caught the case immediately below this block: a DIFFERENT repo of the same project, which is
+  // the multi-repo extend the very next call performs on purpose (ADR-016).
+  //
+  // So a developer whose change spans ai-orchestrator and ai-assistant was told their project's copy
+  // was "already held by another folder" and asked to take it away from themselves, when the server
+  // would have happily added the second repo to the same copy. Verified 2026-08-22.
+  //
+  // It stands down only when it can PROVE the other folder holds a different repo. An entry written
+  // before sourceGitId existed records no repo at all, and for those the honest answer is "cannot
+  // tell", which has to mean warn: skipping on an unknown would quietly remove the guard for exactly
+  // the older entries most likely to have been left behind. Two tests cover that case.
+  // ...and it does not apply at all when the server allows several copies per developer. The hazard
+  // named above is two folders uploading into ONE copy; when each folder gets its own, there is no
+  // blending to prevent. Refusing anyway is what made LAYERED_STORE_MULTIPLE_WORKTREES_PER_DEVELOPER
+  // unreachable: the server answers `multiple_worktrees_allowed: true` on every resolve and the CLI
+  // refused the second worktree regardless.
+  const holder = ctx.multipleWorktreesAllowed ? null : watchState.allLocal(api.currentBaseUrl()).find((e) =>
     e.takeover && e.takeover.sourceProjectId === source.project_id
+    && (e.takeover.sourceGitId == null || e.takeover.sourceGitId === source.git_id)
     && path.resolve(e.folderPath) !== here);
   if (holder) {
     const onBranch = holder.branch ? ` on branch \`${holder.branch}\`` : "";
@@ -154,6 +186,9 @@ async function takeover(pathArg, opts = {}) {
     const manifest = folderSync.buildManifest(repoRoot);
     const filterResult = await agentApi.filterManifest(newGitId, manifest);
     const includedPaths = filterResult.included_paths || filterResult.includedPaths || [];
+    // The gap that cost a day: this command had no oversize warning at all, so a working copy
+    // silently omitted the three largest source files in the repo.
+    folderSync.warnOversizeFiles(manifest, filterResult, (m) => console.log(warn(m)));
     const sizes = {};
     for (const m of manifest) sizes[m.path] = m.size_bytes;
     console.log(`  ${step("●")}  Uploading working tree: ${includedPaths.length} files ` +

package/src/lib/folderSync.js

@@ -126,8 +126,9 @@ const IGNORED_DIRS = new Set([
   "dist", ".venv", "vendor", ".idea", ".gradle", "out",
 ]);
 
-// Server-side per-file cap (256 KiB). Oversize files are skipped server-side at
-// /filter; we surface them as a warning so missing source is never silent.
+// Fallback only, for a server too old to report its own limit. The real limit comes back from
+// /filter as max_file_size_bytes, because a duplicated number is wrong the moment either side is
+// configured: this constant said 256 KiB while a server raised to 2 MiB took the file happily.
 const PER_FILE_CAP_BYTES = 262144;
 
 const DEFAULT_CONCURRENCY = 4;
@@ -482,6 +483,46 @@ async function doInitialSync(gitId, targetDir, includedPaths, { sizes } = {}) {
   return hashes;
 }
 
+
+/**
+ * Tell the developer which files the server is going to drop for being too large.
+ *
+ * <p>This is not cosmetic. `niro new-temp-project` silently dropped a developer's three largest source
+ * files -- the ones the whole branch was about -- because the warning lived only in `niro init`. Niro
+ * then answered questions about those files from the shared project's older copy, confidently, with
+ * nothing on screen to say the working copy did not contain them.
+ *
+ * Uses the limit the SERVER reports, so it cannot drift from what the server actually did. Falls back
+ * to the built-in constant only when talking to a server too old to report one.
+ *
+ * Cross-referenced against excluded_paths where the server sends it, so a file dropped for some other
+ * reason (a doc, a lockfile, a property file) is not blamed on its size.
+ *
+ * @returns the number of files warned about
+ */
+function warnOversizeFiles(manifest, filterResult, log) {
+  const cap = Number(filterResult.max_file_size_bytes || filterResult.maxFileSizeBytes) || PER_FILE_CAP_BYTES;
+  // Over the limit AND a file that would otherwise have been indexed. The second half is what keeps
+  // this honest: a 900 KiB markdown file is over the limit too, but it was never going to be indexed,
+  // so blaming its size teaches the reader to ignore the warning.
+  //
+  // Deliberately NOT cross-referenced against excluded_paths, though that was the first attempt. It
+  // reads as the more precise test and is strictly worse: a file the server never saw is absent from
+  // that list, so a 3 MB source file went unwarned in testing. Size plus type needs no agreement
+  // between two lists to be right.
+  const hits = (manifest || []).filter((m) =>
+    m.size_bytes > cap && isUploadableName(m.path.split("/").pop()));
+  for (const m of hits) {
+    log(`       \u26a0 ${m.path} (${Math.round(m.size_bytes / 1024)} KiB) is over this server's `
+      + `${Math.round(cap / 1024)} KiB per-file limit \u2014 it will NOT be indexed.`);
+  }
+  if (hits.length) {
+    log(`       ${hits.length} file(s) will be missing from this project. Niro will answer about them `
+      + "from whatever version it already has, if any.");
+  }
+  return hits.length;
+}
+
 module.exports = {
   buildManifest,
   walkDir,
@@ -500,4 +541,5 @@ module.exports = {
   IGNORED_DIRS,
   BATCH_SIZE,
   PER_FILE_CAP_BYTES,
+  warnOversizeFiles,
 };

package/src/lib/git.js

@@ -99,6 +99,28 @@ function inspect(startDir) {
   return { repoRoot: found.repoRoot, originUrl, branch };
 }
 
+/**
+ * The root of the MAIN working tree for `repoRoot`.
+ *
+ * A linked worktree (`git worktree add`) is its own folder on its own branch, but Niro onboarding is
+ * recorded against the folder that was actually onboarded, which is the main checkout. Without this a
+ * worktree has NO local identity: nothing in ~/.niro/projects.json is keyed by its path, so the repo it
+ * belongs to cannot be named at all. That is why `niro new-temp-project` could not be run from a
+ * worktree of a repo with no git remote, which is the layered store's main use case.
+ *
+ * Falls back to `repoRoot` itself when this IS the main working tree, when git cannot answer, or when
+ * the common dir is not the usual `<root>/.git` (a bare repo, or an unusual layout). That fallback is
+ * the behaviour that existed before this function, so it can only add an answer, never change one.
+ */
+function mainWorktreeRoot(repoRoot) {
+  if (!repoRoot) return null;
+  const common = gitOut("git rev-parse --git-common-dir", repoRoot);
+  if (!common) return repoRoot;
+  const abs = path.resolve(repoRoot, common);
+  if (path.basename(abs) !== ".git") return repoRoot;
+  return path.dirname(abs);
+}
+
 /**
  * Run ONE `git check-ignore --stdin` in `repoRoot` and report BOTH the matched
  * paths AND whether the check itself succeeded. Paths must be POSIX-relative to
@@ -187,4 +209,5 @@ function isTracked(repoRoot, relativePath) {
   }
 }
 
-module.exports = { inspect, deriveRepoName, checkIgnored, checkIgnoredPaths, redactRemoteCreds, isTracked };
+module.exports = { inspect, mainWorktreeRoot, deriveRepoName, checkIgnored, checkIgnoredPaths,
+  redactRemoteCreds, isTracked };

package/src/lib/resolveContext.js

@@ -27,9 +27,17 @@
  *
  * Never logs secrets. Resolution failures degrade gracefully (state: "error")
  * rather than throwing, so callers/agents can branch on `state`.
+ *
+ * A git URL is not an identity every repo has. `niro init` on a folder with no remote registers it
+ * with a synthetic `local://<name>` URL (see init.js / add-repo.js) that this module never sends back,
+ * and a folder that gains a remote AFTER onboarding keeps the URL it had at the time. Either way the
+ * URL join can never match, so when it comes back empty this falls back to the repo id recorded for
+ * the folder locally, and asks the server by that instead. See resolveByLocalGitId below.
  */
+const path = require("path");
 const git = require("./git");
 const api = require("./api");
+const watchState = require("./watchState");
 
 async function resolveContext(startPath = process.cwd(), opts = {}) {
   const { repoRoot, originUrl, branch } = git.inspect(startPath);
@@ -39,7 +47,11 @@ async function resolveContext(startPath = process.cwd(), opts = {}) {
   }
 
   if (!originUrl) {
-    return { gitRoot: repoRoot, repoUrl: null, branch: branch || null, state: "no_origin", projects: [] };
+    // No remote to ask about, but the folder may still be a repo Niro knows: onboarding does not
+    // require one. Try the local identity before giving up.
+    return resolveByLocalGitId(repoRoot, branch, opts, {
+      gitRoot: repoRoot, repoUrl: null, branch: branch || null, state: "no_origin", projects: [],
+    });
   }
 
   // Omit branch when null (detached HEAD) -> URL-only resolve. Do NOT normalize
@@ -62,13 +74,83 @@ async function resolveContext(startPath = process.cwd(), opts = {}) {
   }
 
   const projects = normalizeProjects(data);
-  return {
+  const byUrl = {
     gitRoot: repoRoot,
     repoUrl: originUrl,
     branch: branch || null,
     state: projects.length ? "resolved" : "unresolved",
     projects,
+    // Whether THIS server lets a developer hold more than one working copy of a project. It is a
+    // property of the server's configuration, not of the match, and it was being dropped here: the
+    // payload carries it on every resolve precisely so the CLI can stop applying a limit the server
+    // no longer enforces, and nothing in the CLI read it. The effect was that the server-side
+    // multi-worktree support could not be reached from any client.
+    multipleWorktreesAllowed: !!(data && data.multiple_worktrees_allowed),
   };
+  if (projects.length) return byUrl;
+  // The remote matched nothing. That is the normal answer for a folder onboarded before it had this
+  // remote, whose stored URL is the `local://` form. Same fallback as the no-origin case.
+  return resolveByLocalGitId(repoRoot, branch, opts, byUrl);
+}
+
+/**
+ * Resolve by the repo id this machine already recorded for the folder, and return `unresolved`
+ * unchanged when that cannot be done. Only ever called after the URL join came back empty, so it can
+ * add a match but never replace one.
+ *
+ * The id is exact where a URL is a guess: `local://demo` is derived from the folder name, so two
+ * unrelated folders both called `demo` would resolve to each other, while the id names one repo.
+ */
+async function resolveByLocalGitId(repoRoot, branch, opts, unresolved) {
+  const apiUrl = opts.apiUrl || api.currentBaseUrl();
+  for (const gitId of localGitIdCandidates(repoRoot, apiUrl)) {
+    const query = { git_id: gitId };
+    if (branch) query.branch = branch;
+    let data;
+    try {
+      data = await api.get("/api/projects/resolve", { query, apiUrl: opts.apiUrl });
+    } catch {
+      // A server that predates `git_id` rejects the whole request, and would reject it for every
+      // candidate. Give back exactly what this folder resolved to before the parameter existed.
+      return unresolved;
+    }
+    const projects = normalizeProjects(data);
+    if (projects.length) {
+      return {
+        ...unresolved,
+        state: "resolved",
+        projects,
+        multipleWorktreesAllowed: !!(data && data.multiple_worktrees_allowed),
+      };
+    }
+  }
+  return unresolved;
+}
+
+/**
+ * Repo ids worth asking the server about for this folder, most specific first.
+ *
+ * Two folders are consulted: this one, and the MAIN working tree when this is a linked worktree. The
+ * second is the one that matters. A worktree is never itself onboarded, so it has no entry of its own,
+ * and looking only at the folder we are standing in is why a worktree could not be resolved at all.
+ *
+ * A folder that has already been taken over holds the COPY's gitId in `gitId`; the repo to resolve is
+ * the source it was taken from, which is why `takeover.sourceGitId` wins where it is present. Without
+ * that a re-run would ask about a temporary project's own repo, which the server correctly refuses.
+ */
+function localGitIdCandidates(repoRoot, apiUrl) {
+  const folders = [path.resolve(repoRoot)];
+  const main = git.mainWorktreeRoot(repoRoot);
+  if (main && path.resolve(main) !== folders[0]) folders.push(path.resolve(main));
+
+  const ids = [];
+  for (const folder of folders) {
+    const entry = watchState.get(folder, apiUrl);
+    if (!entry) continue;
+    const id = (entry.takeover && entry.takeover.sourceGitId) || entry.gitId;
+    if (id && !ids.includes(id)) ids.push(id);
+  }
+  return ids;
 }
 
 /**
@@ -129,4 +211,4 @@ function projectIdFromCreateResponse(project) {
   return id.trim();
 }
 
-module.exports = { resolveContext, normalizeProjects, projectIdFromCreateResponse };
+module.exports = { resolveContext, normalizeProjects, projectIdFromCreateResponse, localGitIdCandidates };