@sparkelf/dsh-knowledge-base 0.1.3 → 0.1.5

package/lib/index.js

@@ -2794,6 +2794,20 @@ const BUILT_IN_ROLES = [{
 * file keeps its inode, every other caller keeps their link, and restoring is
 * deleting the note.
 *
+* ### DO NOT "fix" this by moving or deleting the file
+*
+* The obvious-looking change -- make `trash.remove` rename the file into a trash
+* directory, or unlink it -- is WRONG here, and it is the change a future reader is
+* most likely to make. A view entry is a hardlink to the shared authoritative copy:
+* unlinking it removes one link and leaves the data, which looks harmless, but the
+* next `syncView` finds a standing grant with no link and restores it (see above).
+* Moving the file is worse: the authoritative path is the one DataOps grants are
+* written against, so moving it silently invalidates every other caller's grant and
+* makes the document unreachable for everyone, not just the caller who removed it.
+*
+* Removal is a per-caller filter, never a filesystem operation. That is the whole
+* design, and it is why the trash record exists at all.
+*
 * ## What a tombstone is scoped to
 *
 * A tombstone belongs to a CALLER, not to a path: two people sharing a document may
@@ -3192,7 +3206,11 @@ async function syncCallerView(host, config, paths) {
 	};
 	const trash = await readTrash(viewPathFor(viewOptions));
 	if (trash.kind === "unreadable") host.logger?.warn?.(`knowledge-base: unusable trash record for ${caller.userId}: ${trash.reason}`);
-	const hidden = trash.kind === "ready" ? trash.entries.map((entry) => entry.relPath) : [];
+	const hidden = trash.kind === "ready" ? trash.entries.flatMap((entry) => {
+		const placement = bucketOf(entry.relPath, usableDepartmentPath(caller.departmentPathCodes));
+		const viewPath = placement === void 0 ? void 0 : placement.bucket + "/" + placement.inner;
+		return viewPath === void 0 || viewPath === entry.relPath ? [entry.relPath] : [entry.relPath, viewPath];
+	}) : [];
 	const trustResolvedSet = !(paths === void 0 && candidates.length > 0 && allowed.length === 0);
 	const delta = await syncView({
 		...viewOptions,

package/lib/types/client/dropTargetPath.d.ts

@@ -0,0 +1,33 @@
+/**
+ * Where a dropped file actually lands.
+ *
+ * The tree shows a reader a `personal` folder, but the authoritative tree stores every
+ * caller's documents under their own id (`personal/<owner>/<file>`) -- the owner segment
+ * is hidden from the view on purpose, because it is an implementation detail a reader
+ * never typed. The consequence is that a tree row labelled 「个人」 carries the path
+ * `personal`, and writing straight to it puts the file in `personal/` beside the owner
+ * directories, where no view will ever show it: the reader uploads, the progress row says
+ * "done", and the file is invisible.
+ *
+ * This module owns that translation so every drop entry point (the borrowed explorer, the
+ * plugin's own listing, the Home table) answers the same question the same way.
+ *
+ * @module @sparkelf/dsh-knowledge-base/client
+ */
+/**
+ * Resolve a view-relative directory into the authoritative path a write must use.
+ *
+ * A `personal` path gains the caller's id as its second segment, at whatever depth the
+ * drop names: the bucket row (`personal`), a folder inside it (`personal/specs`), or one
+ * nested deeper all resolve to the caller's own subtree. Everything else (`global`,
+ * `department/...`, `''` for the mount root) is already authoritative and passes through.
+ *
+ * A `personal` path with no caller id is REFUSED rather than passed through. Writing to
+ * `personal` without an owner is exactly the defect this function exists to prevent, so
+ * the refusal is explicit: `undefined` means "no safe destination", and the caller reports
+ * it instead of writing somewhere the reader cannot see.
+ * @param viewRelDir - the directory as the VIEW names it (what a tree row carries).
+ * @param callerId - the id the Host reports for the caller, when it is known.
+ * @returns The authoritative relative directory, or undefined when it cannot be resolved.
+ */
+export declare function resolveUploadDir(viewRelDir: string, callerId: string | undefined): string | undefined;

package/lib/types/client/locales.d.ts

@@ -342,6 +342,9 @@ export declare const en: {
     readonly 'step.sshfs-mount': "Mount the share over SSHFS";
     readonly 'step.sshfs-verify': "Verify the SSHFS mount";
     readonly deployLocalOnly: "Deployment steps run on a remote host. This workspace stores documents locally, so there is nothing to deploy.";
+    readonly dropRefusedNoCaller: "Cannot place this upload";
+    readonly dropRefusedNoCallerReason: "The host has not reported your account yet, so the personal folder cannot be resolved. Reload and try again.";
+    readonly progressResize: "Drag to resize";
     readonly shareEmpty: "Nothing has been shared yet.";
     readonly shareGroupReceived: "Inbound";
     readonly shareGroupGiven: "Outbound";

package/lib/types/client/progressRules.d.ts

@@ -9,23 +9,6 @@
  *
  * @module @sparkelf/dsh-knowledge-base/client
  */
-/**
- * Whether the strip may fold now.
- *
- * Folded means "one summary line instead of a list". It folds when every task in both
- * groups reached a terminal state AND the batch has not been folded before -- the
- * second half is what stops it re-folding after a reader expanded a finished batch to
- * read which file failed.
- * @param uploads - the current batch's rows.
- * @param extractions - the extraction tasks the Host reports.
- * @param alreadyFolded - whether a fold already happened for this batch.
- * @returns Whether to fold.
- */
-export declare function shouldFoldStrip(uploads: readonly {
-    state: string;
-}[], extractions: readonly {
-    state: string;
-}[], alreadyFolded: boolean): boolean;
 /**
  * Whether a retry button would help for this state.
  *
@@ -52,3 +35,20 @@ export declare function failureReason(body: {
     error?: unknown;
     code?: unknown;
 } | undefined, status: number): string;
+/** The strip's height bounds, in pixels. */
+export declare const PROGRESS_MIN_HEIGHT = 44;
+export declare const PROGRESS_DEFAULT_HEIGHT = 180;
+/** The share of the panel's height the strip may take, leaving the tree the rest. */
+export declare const PROGRESS_MAX_SHARE = 0.6;
+/**
+ * Clamp a dragged height into the strip's legal range.
+ *
+ * The upper bound is a share of the PANEL, not a constant: the strip must never grow
+ * until the file tree is unreachable, and how much room that is depends on how tall the
+ * panel currently is. A 600px panel and a 1200px panel therefore allow different
+ * maximums, which is what keeps the tree visible on both.
+ * @param desired - the height the pointer asked for.
+ * @param panelHeight - the panel's own height, when known.
+ * @returns The height to use.
+ */
+export declare function clampProgressHeight(desired: number, panelHeight: number | undefined): number;

package/lib/types/trash.d.ts

@@ -15,6 +15,20 @@
  * file keeps its inode, every other caller keeps their link, and restoring is
  * deleting the note.
  *
+ * ### DO NOT "fix" this by moving or deleting the file
+ *
+ * The obvious-looking change -- make `trash.remove` rename the file into a trash
+ * directory, or unlink it -- is WRONG here, and it is the change a future reader is
+ * most likely to make. A view entry is a hardlink to the shared authoritative copy:
+ * unlinking it removes one link and leaves the data, which looks harmless, but the
+ * next `syncView` finds a standing grant with no link and restores it (see above).
+ * Moving the file is worse: the authoritative path is the one DataOps grants are
+ * written against, so moving it silently invalidates every other caller's grant and
+ * makes the document unreachable for everyone, not just the caller who removed it.
+ *
+ * Removal is a per-caller filter, never a filesystem operation. That is the whole
+ * design, and it is why the trash record exists at all.
+ *
  * ## What a tombstone is scoped to
  *
  * A tombstone belongs to a CALLER, not to a path: two people sharing a document may

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@sparkelf/dsh-knowledge-base",
-  "version": "0.1.3",
+  "version": "0.1.5",
   "description": "DataOps-backed knowledge base for DeepSeek Harness: a left-sidebar destination, Settings configuration, and index tooling over a mounted NAS view.",
   "type": "module",
   "main": "./lib/index.js",