@tpsdev-ai/flair 0.30.0 → 0.31.1

package/dist/resources/migrations/data-dir.js

@@ -0,0 +1,205 @@
+/**
+ * data-dir.ts — resolves the directory the migration subsystem owns
+ * (`<dataDir>/.migrations/{state.json,lock,snapshots,exports}`), and proves
+ * it is actually usable BEFORE the boot cycle commits to it.
+ *
+ * ─── Why this file exists (flair#812) ──────────────────────────────────────
+ * The previous resolution was a single expression, duplicated in
+ * `resources/migration-boot.ts` and `resources/health.ts`:
+ *
+ *     process.env.HDB_ROOT ?? join(homedir(), ".flair", "data")
+ *
+ * Both halves of that were wrong in a way that only shows up off the
+ * developer/default shape:
+ *
+ * 1. `HDB_ROOT` IS NEVER SET BY ANYTHING. It is not a Harper process env
+ *    var — Harper's own root-path env var is `ROOTPATH`
+ *    (`harper`'s `utility/common_utils.ts` reads
+ *    `process.env['ROOTPATH']`; `HDB_ROOT` appears only as a legacy *config
+ *    key* alias in `utility/hdbTerms.ts`, and Harper never reads or writes
+ *    it on `process.env`). flair's own spawner (`src/cli.ts`) exports
+ *    `ROOTPATH`, never `HDB_ROOT`, and `resources/models-dir.ts` already
+ *    reads `ROOTPATH` for exactly this reason. So the `??` left branch was
+ *    dead code and the effective resolution was UNCONDITIONALLY
+ *    `~/.flair/data`, regardless of where Harper's real root actually is.
+ *
+ * 2. `~/.flair/data` is right only by coincidence — it is `flair init`'s
+ *    default data dir, so on a default local install the two happen to
+ *    coincide. On a PROVISIONED install (a service-managed spoke, a
+ *    container, a Harper Fabric component deployment) the process's
+ *    `homedir()` is whatever the service account has: possibly read-only,
+ *    possibly nonexistent, and in general nothing to do with the instance's
+ *    data.
+ *
+ * When `~/.flair/data` is not creatable, EVERY consumer of the old
+ * expression failed — and, critically, failed SILENTLY: the very first
+ * thing `runMigrationCycle` does is `acquireMigrationLock`, whose
+ * `mkdirSync(dirname(lockPath), { recursive: true, mode: 0o700 })` throws
+ * `EACCES`/`ENOENT`, which the runner catches and turns into
+ * `{ ran: false, reason: "lock error: ..." }` — a value `migration-boot.ts`
+ * then discarded. No log line, no state file, no health signal, and every
+ * migration ever shipped skipped forever on that instance. (Contrast
+ * `resources/embeddings-boot.ts`, loaded by the SAME `jsResource` glob:
+ * it touches no filesystem path of its own, which is exactly why embeddings
+ * kept working on the affected shapes while migrations did not.)
+ *
+ * ─── The resolution ─────────────────────────────────────────────────────
+ * An ordered candidate list, first USABLE one wins:
+ *
+ *   1. `FLAIR_MIGRATION_DATA_DIR` — explicit operator override. The escape
+ *      hatch for any deployment shape whose data dir this module cannot
+ *      infer; naming it in the failure message below is what makes an
+ *      unresolvable instance actionable rather than merely reported.
+ *   2. `HDB_ROOT` — retained purely for compatibility with anything that
+ *      may have started setting it because flair once read it. Never set by
+ *      Harper or by flair.
+ *   3. `homedir()/.flair/data` — the historical default, and `flair init`'s
+ *      own data dir. DELIBERATELY still ahead of `ROOTPATH`: on every
+ *      currently-working install this is where the state file already
+ *      lives, and reordering would silently relocate it (costing a
+ *      re-detect pass and orphaning the existing audit record) on instances
+ *      that have no problem at all. This fix is about instances where the
+ *      cycle cannot run, not about relocating ones where it can.
+ *   4. `ROOTPATH` — Harper's real root path. The rescue candidate: it is
+ *      writable by definition on a running instance (Harper is writing its
+ *      own databases there), so a shape whose `homedir()` is unusable still
+ *      gets a stable, per-instance location instead of nothing.
+ *   5. The Harper root INFERRED from this module's own location, but only
+ *      when the running layout is unambiguously a deployed component (see
+ *      `deployedComponentRootPath`). `ROOTPATH` is an env var, and a
+ *      deployment that configures `rootPath` in Harper's config file
+ *      instead of the environment leaves candidate 4 empty — this covers
+ *      that case without guessing.
+ *
+ * "Usable" is probed by DOING THE REAL OPERATION the runner would do —
+ * create `<dir>/.migrations` at 0700 and check it is writable — not by a
+ * proxy check that could disagree with it. The probe is idempotent and, on
+ * a healthy instance, is satisfied by the first candidate without touching
+ * the others.
+ *
+ * If NO candidate is usable, `resolveWritableMigrationDataDir` returns
+ * `dataDir: null` WITH the per-candidate reasons, and the boot path turns
+ * that into a loud console error plus a `failed` progress entry per
+ * registered migration — visible in `/HealthDetail`, `flair doctor` and
+ * `flair quality`'s `instance.migrationsClean`. An instance that cannot run
+ * migrations now says so; that silence was the actual defect.
+ */
+import { accessSync, constants, existsSync, mkdirSync } from "node:fs";
+import { homedir } from "node:os";
+import { basename, dirname, join } from "node:path";
+import { fileURLToPath } from "node:url";
+/** Explicit operator override for the migration data dir (see module doc). */
+export const MIGRATION_DATA_DIR_ENV = "FLAIR_MIGRATION_DATA_DIR";
+/** The subdirectory the migration subsystem owns inside whichever dataDir wins. */
+export const MIGRATIONS_SUBDIR = ".migrations";
+/**
+ * Harper's root path, inferred from where THIS module is running, but ONLY
+ * when the layout is unambiguously a deployed component:
+ *
+ *     <rootPath>/components/<name>/dist/resources/migrations/data-dir.js
+ *
+ * i.e. the directory two levels above `dist/` must itself be named
+ * `components` — Harper's `componentsRoot` convention, and the layout
+ * `deploy_component` produces. That check is what keeps this from firing on
+ * a source checkout or an npm install, where the same arithmetic would
+ * point at an arbitrary parent directory. Returns null whenever the layout
+ * doesn't match, so a non-match contributes no candidate rather than a
+ * guess.
+ *
+ * `moduleUrl` is a parameter purely so a unit test can exercise both the
+ * matching and non-matching layouts without relocating the built file.
+ */
+export function deployedComponentRootPath(moduleUrl = import.meta.url) {
+    try {
+        const here = dirname(fileURLToPath(moduleUrl)); // <component>/dist/resources/migrations
+        const componentDir = dirname(dirname(dirname(here))); // <component>
+        const componentsRoot = dirname(componentDir); // .../components
+        if (basename(componentsRoot) !== "components")
+            return null;
+        return dirname(componentsRoot);
+    }
+    catch {
+        return null;
+    }
+}
+/**
+ * Ordered candidates for the migration data dir. See the module doc for why
+ * this order is what it is — in particular, why `homedir()/.flair/data`
+ * stays ahead of `ROOTPATH`.
+ */
+export function migrationDataDirCandidates(env = process.env, moduleUrl = import.meta.url) {
+    const out = [];
+    const add = (p) => {
+        const trimmed = p?.trim();
+        if (trimmed && !out.includes(trimmed))
+            out.push(trimmed);
+    };
+    add(env[MIGRATION_DATA_DIR_ENV]);
+    add(env.HDB_ROOT);
+    add(join(homedir(), ".flair", "data"));
+    add(env.ROOTPATH);
+    add(deployedComponentRootPath(moduleUrl));
+    return out;
+}
+/**
+ * Probes a candidate by performing the exact operation the runner's lock
+ * acquisition performs (`mkdir -p <dir>/.migrations` at 0700), then
+ * confirming the result is writable. Idempotent: on an already-working
+ * instance this is a no-op stat/mkdir against a directory that already
+ * exists.
+ */
+export function probeMigrationDataDir(dir) {
+    const owned = join(dir, MIGRATIONS_SUBDIR);
+    try {
+        mkdirSync(owned, { recursive: true, mode: 0o700 });
+        accessSync(owned, constants.W_OK | constants.X_OK);
+        return { dir, ok: true };
+    }
+    catch (err) {
+        return { dir, ok: false, reason: err?.message ?? String(err) };
+    }
+}
+/**
+ * Resolves a migration data dir that is proven writable, or reports why not.
+ * Used by the boot path (`resources/migration-boot.ts`), which must not
+ * commit to a directory the runner will then fail to lock.
+ */
+export function resolveWritableMigrationDataDir(env = process.env) {
+    const tried = [];
+    for (const candidate of migrationDataDirCandidates(env)) {
+        const probe = probeMigrationDataDir(candidate);
+        tried.push(probe);
+        if (probe.ok)
+            return { dataDir: candidate, tried };
+    }
+    return { dataDir: null, tried };
+}
+/**
+ * Operator-facing explanation of a total resolution failure — carries the
+ * actor (each path tried), the state (why each was rejected) and the remedy
+ * (the override env var), so the message is actionable at 3am rather than
+ * merely accurate.
+ */
+export function describeUnresolvableDataDir(tried) {
+    const detail = tried.length
+        ? tried.map((t) => `${t.dir} (${t.reason ?? "unusable"})`).join("; ")
+        : "no candidate paths at all";
+    return (`no writable migration data directory — tried ${detail}. ` +
+        `Migrations cannot run on this instance until one exists: point ${MIGRATION_DATA_DIR_ENV} ` +
+        `at a writable directory (or make one of the paths above writable by the account this ` +
+        `instance runs as) and restart.`);
+}
+/**
+ * READ-ONLY counterpart for `/HealthDetail`, which must never create
+ * directories as a side effect of a GET. Prefers whichever candidate
+ * already carries a `.migrations` directory (i.e. the one a boot actually
+ * chose), falling back to the first candidate so the field is never empty.
+ */
+export function resolveMigrationDataDirForRead(env = process.env) {
+    const candidates = migrationDataDirCandidates(env);
+    for (const candidate of candidates) {
+        if (existsSync(join(candidate, MIGRATIONS_SUBDIR)))
+            return candidate;
+    }
+    return candidates[0] ?? join(homedir(), ".flair", "data");
+}

package/dist/resources/migrations/progress.js

@@ -25,6 +25,39 @@ export function seedIdleProgress(ids) {
         }
     }
 }
+/**
+ * Marks every migration that never got off the starting line as `failed`
+ * with `reason` — and ONLY those (flair#812).
+ *
+ * The boot path calls this when a cycle couldn't run, so that a condition
+ * which is really instance-wide (no writable data dir, tables never ready,
+ * the lock itself unobtainable) shows up per-migration, which is the shape
+ * `flair doctor` and `flair quality`'s `instance.migrationsClean` actually
+ * read.
+ *
+ * Restricting it to `idle` entries is load-bearing, not tidiness: a cycle
+ * can fail AFTER some migrations already reached a terminal state — the
+ * pre-hash path, for instance, halts each candidate with its own precise
+ * reason and THEN reports cycle failure. Overwriting those would replace a
+ * specific `halted` (which the runner retries on the next boot, per its
+ * documented contract) with a blanket `failed`, and would flip migrations
+ * that genuinely completed this cycle to failed. Only an entry still `idle`
+ * is one nothing has said anything about yet.
+ *
+ * Returns the ids actually marked, so a caller can tell "nothing had
+ * started" from "the cycle died partway".
+ */
+export function markIdleMigrationsFailed(ids, reason) {
+    const marked = [];
+    for (const id of ids) {
+        const current = progressById.get(id);
+        if (current && current.state !== "idle")
+            continue;
+        progressById.set(id, { id, rowsDone: 0, rowsRemaining: 0, state: "failed", reason });
+        marked.push(id);
+    }
+    return marked;
+}
 export function _resetProgressForTests() {
     progressById.clear();
     cycleStatus = { phase: "idle" };

package/dist/resources/migrations/runner.js

@@ -151,7 +151,21 @@ async function runCycleLocked(deps, lock) {
     const candidates = [];
     for (const migration of deps.registry.list()) {
         if (isShortCircuited(state, migration.id, deps.runningVersion)) {
-            setMigrationProgress({ id: migration.id, rowsDone: 0, rowsRemaining: 0, state: "completed" });
+            // flair#812: a short-circuit is an ASSERTION READ OFF A FILE, not an
+            // observation of the corpus — and that file is hand-editable (the
+            // documented remediation for a stuck migration is to correct it by
+            // hand). Reporting it as plain "completed" made a hand-written entry
+            // indistinguishable from a migration this boot actually verified.
+            // The skip itself is unchanged (it is the documented cheap path); it
+            // now just says what it is, so `flair doctor` never presents an
+            // unverified claim as a verified one.
+            setMigrationProgress({
+                id: migration.id,
+                rowsDone: 0,
+                rowsRemaining: 0,
+                state: "completed",
+                reason: `recorded complete at ${deps.runningVersion} in ${deps.statePath} — not re-verified this boot`,
+            });
             continue;
         }
         setMigrationProgress({ id: migration.id, rowsDone: 0, rowsRemaining: 0, state: "checking" });
@@ -160,12 +174,18 @@ async function runCycleLocked(deps, lock) {
             pending = await migration.detect();
         }
         catch (err) {
+            // flair#812: a throwing detect() removes this migration from the
+            // candidate set, so a cycle where EVERY detect() throws used to reach
+            // the `nothing pending` return and look like a clean no-op. Log it
+            // with the standard marker as well as recording it in progress.
+            const reason = `detect() threw: ${err?.message ?? String(err)}`;
+            console.error(`[flair-migrations] ${migration.id}: ${reason}`);
             setMigrationProgress({
                 id: migration.id,
                 rowsDone: 0,
                 rowsRemaining: 0,
                 state: "failed",
-                reason: `detect() threw: ${err?.message ?? String(err)}`,
+                reason,
             });
             continue;
         }
@@ -176,6 +196,13 @@ async function runCycleLocked(deps, lock) {
         candidates.push(migration);
     }
     if (candidates.length === 0) {
+        // flair#812: mark the cycle done even on the no-op path. "Nothing was
+        // pending" and "the cycle never ran" are opposite conclusions that used
+        // to produce an IDENTICAL `/HealthDetail` reading (`cyclePhase: "idle",
+        // lastCycleAt: null`), which is exactly why a totally-skipped boot cycle
+        // looked healthy for months. A cycle that reached this line has done its
+        // job, and now says so.
+        setCyclePhase("done");
         return { ran: false, reason: "nothing pending" };
     }
     // ── ONE shared async pre-hash at cycle start (K&S: computed after ready,

package/dist/resources/migrations/state.js

@@ -30,11 +30,22 @@ export function readMigrationState(path) {
         if (!existsSync(path))
             return {};
         const raw = JSON.parse(readFileSync(path, "utf-8"));
-        return raw && typeof raw === "object" ? raw : {};
+        if (raw && typeof raw === "object")
+            return raw;
+        console.warn(`[flair-migrations] ${path} is not a JSON object — ignoring it and re-detecting every migration this boot`);
+        return {};
     }
-    catch {
+    catch (err) {
         // Corrupt/unreadable state — treat as "nothing known yet", never throw.
         // Worst case this costs one extra (cheap, bounded) detect() call.
+        //
+        // flair#812: but SAY SO. This file is hand-edited in practice (the
+        // documented remediation for a stuck migration), and a fat-fingered
+        // edit silently discarding every recorded outcome is precisely the
+        // class of quiet failure this issue is about. The behaviour is
+        // unchanged and still safe — only the silence is fixed.
+        console.warn(`[flair-migrations] could not read ${path} (${err?.message ?? String(err)}) — ` +
+            `treating migration state as empty and re-detecting every migration this boot`);
         return {};
     }
 }

package/dist/resources/models-dir.js

@@ -1,25 +1,34 @@
 /**
  * models-dir.ts — the ONE place that decides where model GGUFs live.
  *
- * Extracted from embeddings-provider.ts (flair#815) so the reranker
- * (rerank-provider.ts) can share the exact same resolution WITHOUT importing
+ * Extracted from embeddings-provider.ts (flair#815) so a second model
+ * consumer could share the exact same resolution WITHOUT importing
  * embeddings-provider: several unit-isolated tests `mock.module()` the whole
  * embeddings-provider module (with only the named exports THEY consume), and
  * bun's module cache is process-wide — so any new cross-module import of
  * embeddings-provider from another resource makes those mocks incomplete and
  * kills unrelated test files at module load. This module is tiny, pure
- * node-stdlib, and never mocked, so both providers (and any future model
- * consumer) can depend on it safely.
+ * node-stdlib, and never mocked, so any model consumer can depend on it
+ * safely.
+ *
+ * The second consumer that motivated the split (the cross-encoder reranker)
+ * has since been removed (flair#893), leaving the embedding engine as the
+ * only caller. The module stays split anyway, and deliberately: the
+ * `mock.module()` hazard above is a property of embeddings-provider, not of
+ * the reranker, so folding this back in would re-arm it for whatever the next
+ * model consumer turns out to be. It is also the single documented source of
+ * truth for the models dir, independently tested as such.
  */
 import { existsSync } from "node:fs";
 import { homedir } from "node:os";
 import { join } from "node:path";
 /**
- * Resolve the directory model GGUFs live in / download into — shared by the
- * embedding engine (embeddings-boot.ts's `register()` options) and the
- * cross-encoder reranker (rerank-provider.ts, flair#815 — it used to hardcode
- * `<cwd>/models`, silently failing open wherever Harper's cwd wasn't the
- * models location).
+ * Resolve the directory model GGUFs live in / download into — used by the
+ * embedding engine (embeddings-boot.ts's `register()` options), and the
+ * resolution any future model consumer should use rather than re-deriving its
+ * own. flair#815 exists because a consumer that hardcoded `<cwd>/models`
+ * silently failed open wherever Harper's cwd wasn't the models location; the
+ * fix was to give the decision exactly one home, which is this function.
  *
  * Resolution order (everything writable, never the read-only package dir):
  *   1. FLAIR_MODELS_DIR        — explicit operator/docker override.

package/dist/resources/presence-internal.js

@@ -2,7 +2,12 @@ function presenceDelegationContext(auth) {
     const agentAuth = auth.kind === "agent"
         ? { agentId: auth.agentId, isAdmin: auth.isAdmin }
         : { agentId: "internal", isAdmin: true };
-    return { request: { _flairAgentAuth: agentAuth } };
+    // `__flairInternal` marks the `internal` branch as DELIBERATE (flair#936) —
+    // an "internal" verdict relayed here is a trusted in-process call this file
+    // has already established, not a caller who forgot to pass a context. It is
+    // read only by resources/agent-auth.ts's accidental-omission warning; it
+    // grants nothing and is never consulted for an authorization decision.
+    return { request: { _flairAgentAuth: agentAuth }, __flairInternal: true };
 }
 /**
  * The full presence roster (one row per agent — bounded, per the K&S

package/dist/resources/record-owner-guard.js

@@ -0,0 +1,149 @@
+/**
+ * record-owner-guard.ts — ONE enforcement point for "you may not modify a
+ * record you do not own".
+ *
+ * ─── The defect this deletes ─────────────────────────────────────────────────
+ *
+ * Harper's REST layer maps verbs to resource methods ONE-TO-ONE (see
+ * harper/dist/server/REST.js's method switch): GET→get, POST→post, PUT→put,
+ * PATCH→patch, DELETE→delete. There is no fallback — `patch()` does NOT route
+ * through `put()`. So an ownership rule written inside a resource's `put()` is
+ * enforced on PUT and on nothing else, and a resource with no `patch()` override
+ * reaches the table with only its `allow*` gate, which is typically
+ * `allowVerified()` — "any verified agent".
+ *
+ * Almost every flair resource wrote its per-record rules in `put()`. That is not
+ * a mistake anyone made once; it is what the resource model invites, because
+ * `put()` is where the write logic naturally goes and nothing anywhere says the
+ * other verbs exist. Fixing it resource-by-resource would mean N hand-written
+ * guards — N chances to get one subtly wrong — and would still leave the NEXT
+ * resource broken by default, because its author would have to know this file
+ * exists to be safe. So the rule lives here instead, once, on the path every
+ * HTTP request already takes.
+ *
+ * ─── The rule, and why it is this narrow ─────────────────────────────────────
+ *
+ *   On a record that ALREADY EXISTS, a non-admin caller whose agent id does not
+ *   match the record's stored owner is refused — on every mutating verb.
+ *
+ * It deliberately says nothing about creation. Over-blocking is the failure mode
+ * a security fix reaches for, and a blunter rule ("the caller must own whatever
+ * it names") would break real flows: Presence heartbeats arrive at the
+ * collection with no record yet, credential provisioning creates rows for other
+ * principals, and a MemoryGrant's `granteeId` is SUPPOSED to be someone else.
+ * Restricting this to records that exist means the guard can only ever narrow
+ * mutation of another agent's data. It cannot break a create, and it cannot
+ * break an agent writing its own record.
+ *
+ * ─── Owner is read from STORED STATE, never from the request body ────────────
+ *
+ * The guards this replaces compared the owner field in the request BODY — the
+ * owner the CALLER CLAIMS — and denied only when that field was present and
+ * mismatched. A body that simply omitted it was compared against nothing and
+ * passed, whatever record the URL named. Harper binds the write to the URL's id,
+ * not to the body, so body-derived authorization was answering a question nobody
+ * asked. That is the same defect as the verb gap wearing different clothes: an
+ * authorization decision made against attacker-supplied data instead of stored
+ * state. Both are closed here, together, because closing one leaves the other
+ * reachable.
+ *
+ * Per-resource body checks (no-forge attribution on CREATE) still belong in the
+ * resources — they answer a different question, "may you attribute a NEW record
+ * to someone else", which this guard does not address.
+ *
+ * ─── Keeping this honest as the codebase grows ───────────────────────────────
+ *
+ * OWNER_FIELDS below is static and PR-reviewed, matching the posture of
+ * resources/record-types.ts. A static map alone would rot, so
+ * test/unit/record-owner-guard-coverage.test.ts parses `schemas/*.graphql` and
+ * FAILS when a table declares an owner-shaped column and is neither listed here
+ * nor exempted with a stated reason. A table added later enters that test's
+ * scope the moment it declares the column — nobody has to know this file exists.
+ */
+/**
+ * Table → the attribute naming the principal that owns a row.
+ *
+ * Derived from the columns actually declared in `schemas/*.graphql`, and pinned
+ * against them by the coverage test. Tables with no resource class are listed
+ * anyway: costing nothing when the route does not exist is much better than
+ * being absent on the day someone adds one.
+ */
+export const OWNER_FIELDS = Object.freeze({
+    Credential: "principalId",
+    Integration: "agentId",
+    Memory: "agentId",
+    MemoryCandidate: "agentId",
+    MemoryGrant: "ownerId",
+    MemoryUsage: "agentId",
+    OAuthAuthCode: "principalId",
+    OAuthToken: "principalId",
+    OrgEvent: "authorId",
+    Presence: "agentId",
+    Relationship: "agentId",
+    Soul: "agentId",
+    WorkspaceState: "agentId",
+});
+/**
+ * Tables that declare an owner-shaped column but are deliberately NOT guarded
+ * here, each with the reason. The coverage test accepts these and rejects
+ * anything else, so an omission has to be argued rather than merely happen.
+ */
+export const OWNER_GUARD_EXEMPT = Object.freeze({
+    // The principal table's own rule is "the record IS the caller", not "the
+    // record has an owner column" — a principal may edit itself, and only an
+    // admin may change anyone's admin status. That is enforced in
+    // resources/Agent.ts's shared write-authorization helper, which both its
+    // put() and its patch() route through.
+    Agent: "self-ownership by primary key; enforced in resources/Agent.ts for every verb",
+});
+/** The verbs that can mutate a record, and therefore need the rule applied. */
+export const MUTATING_METHODS = Object.freeze(["POST", "PUT", "PATCH", "DELETE"]);
+export function isMutatingMethod(method) {
+    return MUTATING_METHODS.includes(method.toUpperCase());
+}
+/**
+ * Resolve a request path to the guarded table and record id it addresses, or
+ * null when the path is not a guarded single-record route.
+ *
+ * Matches `/<Table>/<id>` ONLY. A collection path (`/<Table>`) addresses no
+ * existing record, so there is nothing to own and nothing to check — that is the
+ * "creation is untouched" property, expressed as a parse rather than a special
+ * case. The table segment is matched EXACTLY so `/SoulFeed/x` can never be read
+ * as a `Soul` route.
+ */
+export function resolveGuardedRecord(pathname) {
+    const parts = pathname.split("/").filter(Boolean);
+    if (parts.length < 2)
+        return null;
+    const table = parts[0];
+    const ownerField = OWNER_FIELDS[table];
+    if (!ownerField)
+        return null;
+    let id;
+    try {
+        id = decodeURIComponent(parts[1]);
+    }
+    catch {
+        return null; // malformed percent-encoding addresses no record we can resolve
+    }
+    if (!id)
+        return null;
+    return { table, ownerField, id };
+}
+/**
+ * Decide whether a caller may mutate an already-stored record.
+ *
+ * Pure, so the decision is testable without a Harper instance — the middleware
+ * supplies the record it loaded. A record that does not exist, or that carries
+ * no owner value, is NOT refused here: the first is a create (or a 404 the
+ * resource will produce), and the second is a row with nothing to own, neither
+ * of which this rule is about.
+ */
+export function isForbiddenOwnerMutation(record, ownerField, callerAgentId) {
+    if (!record)
+        return false;
+    const owner = record[ownerField];
+    if (owner == null || owner === "")
+        return false;
+    return owner !== callerAgentId;
+}

package/dist/resources/semantic-retrieval-core.js

@@ -3,8 +3,8 @@
 // Extracted from resources/SemanticSearch.ts's post() (Kern-approved
 // refactor, flair#695). Before this module existed,
 // SemanticSearch.post() was one function entangling auth resolution,
-// rate-limiting, HNSW/BM25 retrieval, post-retrieval filtering, the
-// cross-encoder reranker, AND retrievalCount/lastRetrieved hit-tracking side
+// rate-limiting, HNSW/BM25 retrieval, post-retrieval filtering, AND
+// retrievalCount/lastRetrieved hit-tracking side
 // effects — so the ONLY way for MemoryBootstrap (resources/MemoryBootstrap.ts)
 // to get bounded, HNSW-pushed-down candidates was to duplicate the retrieval
 // logic or trip the side effects (an internal bootstrap call spuriously
@@ -16,7 +16,7 @@
 // the HNSW leg query construction (sort/select/conditions/limit), the BM25 +
 // union-RRF hybrid fusion, the per-record temporal/expiry/supersede filters,
 // and the scope.isAllowed() defense-in-depth re-check. It does NOT own: auth
-// resolution, rate-limiting, the reranker, or the retrievalCount/lastRetrieved
+// resolution, rate-limiting, or the retrievalCount/lastRetrieved
 // hit-tracking side effects — those stay in SemanticSearch.post()'s wrapper
 // (resources/SemanticSearch.ts) so an internal caller (bootstrap) never trips
 // them.
@@ -32,7 +32,8 @@
 // Returns results AFTER all filters, sorted best-first by `_score` — bounded
 // ONLY by the `limit` the caller chose to push down (the core never
 // multiplies `limit` internally; any overfetch policy — SemanticSearch's
-// CANDIDATE_MULTIPLIER, rerank-topN widening — is the CALLER's decision, made
+// CANDIDATE_MULTIPLIER, MemoryBootstrap's K formula — is the CALLER's
+// decision, made
 // before calling in). Never exposes which internal leg (BM25+RRF hybrid vs.
 // legacy HNSW-only vs. keyword-only fallback) produced a given result — the
 // output shape is identical regardless of `hybrid`.