@panaversity/ksor 0.0.60 → 0.0.61

package/CHANGELOG.md

@@ -1,5 +1,51 @@
 # @panaversity/ksor
 
+## 0.0.61
+
+### Patch Changes
+
+- c8df2a0: `pnpm dev` now drops a document that is deleted or moved while it runs (#274).
+
+  The dev server keeps a staged copy of the record, and its watcher carried edits
+  and new documents into that copy but never removals. A document deleted during
+  a review went on answering 200 at its old url and stayed in the sidebar, and a
+  moved one was listed twice, once at each path, until the dev server restarted.
+  Nothing told the owner to restart.
+
+  The refresh now removes every staged file the record no longer holds, and every
+  folder that leaves empty, so the deleted or moved document answers 404 at its
+  old url and leaves the sidebar within about a second. A document whose audience
+  is edited so that the dev viewer may no longer read it leaves the same way.
+
+  Removals were held back because a 2026-08-18 measurement found that deleting a
+  staged file took the dev server down. On fumadocs-mdx 15.4.0 and Next 16.3.3
+  it recovers on its own, but the race behind it remains: Turbopack can compile
+  before fumadocs has regenerated the collection, so the dev log may show
+  `Module not found` for the removed file, and a request in that moment can
+  answer with a 500. Measured on a fresh scaffold, another page polled every 20ms
+  did so one to four times in 6 of 8 removals, then answered 200 again. Builds
+  are unaffected: they never run the watcher.
+
+  An existing project takes the fix with `ksor migrate --write-site`, which
+  reissues `system/site/lib/stage-knowledge.ts` with the rest of the site.
+
+- 7d2e28a: A new npm or bun scaffold builds its site again.
+
+  `mdast-util-to-markdown@2.1.3`, published 2026-09-27, broke the MDX stringifier
+  of `fumadocs-core@16.15.4`, the version the scaffold pins. Any page with bold or
+  italic text sent it into recursion without end, so `npm run build` and
+  `bun run build` failed with `RangeError: Maximum call stack size exceeded`
+  (fuma-nama/fumadocs#3604). The npm and bun scaffolds ship no lockfile, so a
+  fresh install picked up 2.1.3. Their root `package.json` now has
+  `"overrides": { "mdast-util-to-markdown": "2.1.2" }`, and their README explains
+  it. The pnpm scaffold has not changed, because its committed lockfile already
+  holds 2.1.2.
+
+  If you scaffolded with npm or bun and your build now fails this way, add the
+  same `overrides` entry to your root `package.json` and install again. Remove the
+  entry when you move `fumadocs-core` to 16.15.15 or later, which has the
+  upstream fix.
+
 ## 0.0.60
 
 ### Patch Changes

package/dist/cli.mjs

@@ -12337,6 +12337,20 @@ const SCRIPT_BODIES = {
 	}
 };
 /**
+* Versions of dependencies of dependencies that npm and bun must be told to
+* hold, written as `overrides`, which both read. pnpm needs none here: its
+* committed lockfile already holds each one.
+*
+* mdast-util-to-markdown 2.1.3 (2026-09-27) writes bold and italic only
+* through a handler's `attention`. The MDX stringifier of the fumadocs-core
+* 16.15.4 that the site pins wraps every handler without it, so the site
+* build recursed until the stack overflowed (issue #276,
+* fuma-nama/fumadocs#3604, fixed in fumadocs-core 16.15.15). Remove the entry,
+* and the README paragraph that explains it, in the change that moves the site
+* to that Fumadocs: init-manager.integration.test.ts fails until they are gone.
+*/
+const OVERRIDES = { "mdast-util-to-markdown": "2.1.2" };
+/**
 * Rewrite the scaffold's root package.json for the manager. Structured — a
 * JSON transform, never string surgery — because the manifest is the one
 * file where a half-applied spelling map would still parse and then lie.
@@ -12351,7 +12365,8 @@ function transformManifest(source, manager) {
 			...parsed.scripts,
 			...SCRIPT_BODIES[manager]
 		},
-		workspaces: [...WORKSPACE_GLOBS]
+		workspaces: [...WORKSPACE_GLOBS],
+		overrides: { ...OVERRIDES }
 	};
 	return `${JSON.stringify(out, null, 2)}\n`;
 }

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@panaversity/ksor",
-  "version": "0.0.60",
+  "version": "0.0.61",
   "description": "Knowledge System of Record — compile governed markdown into a static site for people and an MCP server for AI agents, with citations and measured abstention.",
   "keywords": [
     "abstention",

package/templates/scaffold/README.md

@@ -94,6 +94,15 @@ never picks up a day-zero compromised release. bun has no equivalent — its
 default refusal of dependency install scripts covers the OTHER half of that
 posture, and this sentence is the disclosure.
 
+<!-- /ksor:pm -->
+<!-- ksor:pm npm bun -->
+
+`package.json` also holds one dependency of a dependency back: `overrides`
+keeps `mdast-util-to-markdown` at 2.1.2. With the `fumadocs-core` this scaffold
+pins, version 2.1.3 makes the site build recurse until it runs out of stack
+([fumadocs#3604](https://github.com/fuma-nama/fumadocs/issues/3604)). Delete the
+override when you move `fumadocs-core` to 16.15.15 or later, which has the fix.
+
 <!-- /ksor:pm -->
 
 ---

package/templates/scaffold/system/site/lib/stage-knowledge.ts

@@ -672,15 +672,15 @@ function fillStage(recordDir: string, stageDir: string, development: boolean): v
 }
 
 /**
- * Dev only: carry edits AND ARRIVALS into the stage, so `pnpm dev` shows the
- * record as the owner is writing it rather than as it stood when the server
- * started — the regenerated indexes included, so a retitled document is
+ * Dev only: carry edits, ARRIVALS and REMOVALS into the stage, so `pnpm dev`
+ * shows the record as the owner is writing it rather than as it stood when the
+ * server started — the regenerated indexes included, so a retitled document is
  * retitled in its folder's listing too.
  *
- * Adds and edits — never removals. The 2026-08-18 measurement this refused
- * adds on ("fumadocs' own watcher cannot see a dot-prefixed collection
- * directory") no longer holds: on fumadocs-mdx 15.3.0 a file written into
- * `.staged-knowledge` DOES regenerate the collection, twice-observed as
+ * Arrivals first. The 2026-08-18 measurement this refused adds on ("fumadocs'
+ * own watcher cannot see a dot-prefixed collection directory") no longer
+ * holds: on fumadocs-mdx 15.3.0 a file written into `.staged-knowledge` DOES
+ * regenerate the collection, twice-observed as
  * `[MDX] generated files` in the dev log. What actually kept a new document
  * off every surface was this function, which walked the STAGE and skipped
  * anything the stage did not already hold — so a plan entry with no file on
@@ -692,11 +692,23 @@ function fillStage(recordDir: string, stageDir: string, development: boolean): v
  * this way before the stage existed (0.0.40 serves an added document at 200),
  * so this is a regression repaired rather than a feature.
  *
- * REMOVALS still wait for the restart `pnpm dev` already needs for
- * instance.md: the same measurement found a deleted file leaves fumadocs'
- * generated imports pointing at something gone, which takes the dev server
- * down rather than showing a stale page. An arrival has no such failure mode
- * — nothing points at a file that has only just appeared.
+ * REMOVALS used to wait for a restart: the same 2026-08-18 measurement found a
+ * deleted file left fumadocs' generated imports pointing at something gone,
+ * which took the dev server down. On fumadocs-mdx 15.4.0 and Next 16.3.3 it
+ * does not stay down. Measured 2026-10-01 on a fresh scaffold: each document
+ * deleted or moved while `pnpm dev` ran regenerated the collection (`[MDX]
+ * generated files`), answered 404 at its old url within about a second and
+ * left the sidebar, and every other page answered 200 with no restart.
+ *
+ * What remains is a race, not an outage. Turbopack can compile
+ * `.source/server.ts` before fumadocs has rewritten it, so the log shows
+ * `Module not found` for the removed file and a request in that window answers
+ * 500: another page, polled every 20ms, did so one to four times in 6 of 8
+ * removals, then answered 200 again. Both watchers react to the same unlink,
+ * so nothing here can order them. Errors that clear themselves are still the
+ * better failure: before this, a deleted document went on serving at 200 and
+ * stayed in the sidebar, and a moved one was listed twice, until someone
+ * thought to restart (issue #274).
  */
 function refreshStage(recordDir: string, stageDir: string): void {
   // Under the lock like every other write here: a save landing while another
@@ -719,6 +731,9 @@ function refreshStage(recordDir: string, stageDir: string): void {
       mkdirSync(path.dirname(staged), { recursive: true });
       writeFileSync(staged, bytes);
     }
+    // Removals from the plan too: a staged file the plan no longer holds was
+    // deleted, moved, or withdrawn from this viewer, and is not the record.
+    pruneExcept(stageDir, new Set(plan.entries.map((e) => path.resolve(stageDir, e.rel))));
     writeManifest(stageDir, plan.manifest);
   });
 }
@@ -867,6 +882,14 @@ function publishSims(sourceDir: string): void {
  * nothing else writes it), so what is not published now does not belong.
  */
 function pruneSims(target: string, published: ReadonlySet<string>): void {
+  pruneExcept(target, published);
+}
+
+/**
+ * Every file under `target` whose resolved path `keep` does not hold, removed,
+ * and every directory that leaves empty. `target` itself always stays.
+ */
+function pruneExcept(target: string, keep: ReadonlySet<string>): void {
   const walk = (dir: string): boolean => {
     let entries;
     try {
@@ -882,7 +905,7 @@ function pruneSims(target: string, published: ReadonlySet<string>): void {
         else empty = false;
         continue;
       }
-      if (published.has(path.resolve(here))) {
+      if (keep.has(path.resolve(here))) {
         empty = false;
         continue;
       }