@rubytech/create-maxy-code 0.1.412 → 0.1.414

package/dist/__tests__/installer-cwd-pin-and-auth-verify.test.js

@@ -0,0 +1,82 @@
+// Static-grep contracts for Task 1462 — the installer must survive being
+// invoked from a working directory that deployPayload() later wipes.
+//
+// Three defects were compounding on the customer Pi upgrade:
+//   A. main() never pins the process CWD, so once deployPayload() rmSync's the
+//      operator's CWD (they ran `npx` from inside ~/.<brand>/platform), every
+//      subprocess inherits a deleted inode → JVM `getcwd() failed` and Bun
+//      ENOENT.
+//   B. resetNeo4jAuth returned the freshly-generated password even when the
+//      15x cypher-shell verify loop never passed, so the app persisted a
+//      password Neo4j never actually accepted.
+//   C. the version marker was stamped mid-deployPayload, before plugin
+//      registration could abort, so an aborted upgrade reported success.
+//
+// Why static-grep, not behaviour: the touched paths spawn (systemctl, brew,
+// launchctl, cypher-shell) and run the whole install on import — the same
+// reason macos-darwin-branch.test.ts contracts resetNeo4jAuth by shape. This
+// suite pins the code shape so a refactor that drops a fix fails loudly here.
+import test from "node:test";
+import assert from "node:assert/strict";
+import { readFileSync } from "node:fs";
+import { fileURLToPath } from "node:url";
+import { dirname, resolve } from "node:path";
+// dist/__tests__/installer-cwd-pin-and-auth-verify.test.js → ../../src/index.ts
+const here = dirname(fileURLToPath(import.meta.url));
+const INDEX_TS = resolve(here, "../../src/index.ts");
+const SRC = readFileSync(INDEX_TS, "utf-8");
+// --- Defect A: CWD pin ---
+test("installer pins the process CWD to a never-wiped directory at startup", () => {
+    assert.match(SRC, /process\.chdir\(/, "startup must call process.chdir to escape a wipeable inherited CWD");
+    // The pin target is the operator HOME (never wiped — deployPayload only
+    // rmSync's subdirs of INSTALL_DIR), with a "/" fallback if the chdir throws.
+    assert.match(SRC, /process\.chdir\(process\.env\.HOME\s*\?\?\s*["']\/["']\)/, "CWD pin target must be process.env.HOME with a '/' fallback");
+    assert.match(SRC, /process\.chdir\(["']\/["']\)/, "a '/' fallback chdir must exist for when the HOME chdir throws");
+});
+test("installer logs the resolved pinned CWD", () => {
+    assert.match(SRC, /cwd-pinned to=/, "startup must emit a grep-able resolved-CWD line");
+});
+test("the CWD pin runs before deployPayload wipes the tree", () => {
+    const chdirAt = SRC.indexOf("process.chdir(");
+    // `deployPayload();` (with semicolon) is the call site — the definition is
+    // `function deployPayload(): void`, so the semicolon disambiguates.
+    const deployCallAt = SRC.indexOf("deployPayload();");
+    assert.ok(chdirAt !== -1 && deployCallAt !== -1, "both anchors must exist");
+    assert.ok(chdirAt < deployCallAt, "process.chdir must appear before the deployPayload() call so no rmSync runs under a live inherited CWD");
+});
+// --- Defect B: resetNeo4jAuth verifies before returning ---
+test("resetNeo4jAuth records whether the post-reset auth check ever passed", () => {
+    assert.match(SRC, /\[neo4j-auth-reset\] verified=/, "resetNeo4jAuth must emit a verified=<bool> port=<n> post-condition line");
+});
+test("resetNeo4jAuth throws instead of returning an unverified password", () => {
+    // The old shape returned `password` unconditionally after the wait loop.
+    // The fix guards the return on a `verified` flag and throws otherwise.
+    const fn = SRC.slice(SRC.indexOf("function resetNeo4jAuth"), SRC.indexOf("function redactInstallLogs"));
+    assert.ok(fn.length > 0, "resetNeo4jAuth body must be locatable");
+    const gateIdx = fn.search(/if\s*\(\s*!verified\s*\)/);
+    assert.ok(gateIdx !== -1, "resetNeo4jAuth must branch on !verified");
+    assert.match(fn, /throw new Error\(/, "resetNeo4jAuth must throw when the reset never verified");
+    // The credential can only be returned on the verified path: the !verified
+    // throw-gate must sit BEFORE `return password`, so an unverified reset can
+    // never fall through to a return. A positional check, not a
+    // `}...return password` regex — the fixed code legitimately has the
+    // throw-block's own `}` immediately before the return.
+    const returnIdx = fn.lastIndexOf("return password");
+    assert.ok(returnIdx !== -1, "resetNeo4jAuth must still return the password on the verified path");
+    assert.ok(gateIdx < returnIdx, "the !verified throw-gate must precede `return password` so an unverified reset can never return a credential");
+});
+// --- Defect C: version marker gated on full completion ---
+test("deployPayload no longer stamps the version marker mid-deploy", () => {
+    const dp = SRC.slice(SRC.indexOf("function deployPayload"), SRC.indexOf("function registerLocalAndExternalPlugins"));
+    assert.ok(dp.length > 0, "deployPayload body must be locatable");
+    assert.ok(!/hostname\}-version`\)[\s\S]*?writeFileSync\([^\n]*PKG_VERSION/.test(dp), "deployPayload must not write the version marker — it moved to the end of a fully-successful install");
+});
+test("version marker is written only after plugin registration completes", () => {
+    // Anchor on the call site (`...Plugins();` with semicolon), not the
+    // `function ...Plugins(): void` definition — the definition sits far above
+    // main() and would make this pass trivially.
+    const registerCallAt = SRC.indexOf("registerLocalAndExternalPlugins();");
+    const markerAt = SRC.indexOf("version-marker written");
+    assert.ok(registerCallAt !== -1 && markerAt !== -1, "both anchors must exist");
+    assert.ok(markerAt > registerCallAt, "the version-marker write must appear after the registerLocalAndExternalPlugins() call so an aborted run does not report success");
+});

package/dist/index.js

@@ -1338,16 +1338,30 @@ function resetNeo4jAuth(port = DEFAULT_NEO4J_PORT, dataDir = "/var/lib/neo4j", p
         shell("systemctl", ["start", serviceName], { sudo: true });
     }
     console.log("  Waiting for Neo4j to start...");
+    let verified = false;
     for (let i = 0; i < 15; i++) {
         const check = spawnSync("cypher-shell", [
             "-u", "neo4j", "-p", password,
             "-a", `bolt://localhost:${port}`,
             "RETURN 1",
         ], { stdio: "pipe", timeout: 5000 });
-        if (check.status === 0)
+        if (check.status === 0) {
+            verified = true;
             break;
+        }
         spawnSync("sleep", ["2"]);
     }
+    // Post-condition: the new password only becomes authoritative once a
+    // cypher-shell login actually succeeds. Returning an unverified password let
+    // ensureNeo4jPassword persist a credential Neo4j never accepted — a hard
+    // mismatch no restart can heal (Task 1462). The commonest cause of a
+    // never-verifying reset is a corrupted set-initial-password from a deleted
+    // CWD (JVM `getcwd() failed`); the CWD pin removes that, this throw stops the
+    // installer writing a bad password if it still fails.
+    logFile(`[neo4j-auth-reset] verified=${verified} port=${port}`);
+    if (!verified) {
+        throw new Error(`Neo4j auth reset did not verify on port ${port}: cypher-shell RETURN 1 failed on all 15 attempts. The new password was NOT confirmed and will not be persisted. Check the install log for a JVM \`getcwd() failed\` (deleted install CWD) or a Neo4j that never accepted auth.`);
+    }
     return password;
 }
 /**
@@ -2478,10 +2492,10 @@ function deployPayload() {
     // Mirrors checkAdminAuthInvariant() in platform/lib/admins-write/src/index.ts;
     // future divergence between the two should be caught by the test suite.
     runInstallInvariantCheck(persistentUsersFile, join(INSTALL_DIR, "data", "accounts"));
-    // Write version marker so the running platform knows which create-maxy produced this deployment
-    const versionMarkerPath = join(configDir, `.${BRAND.hostname}-version`);
-    writeFileSync(versionMarkerPath, PKG_VERSION, "utf-8");
-    console.log(`  [install] version-marker written path=${versionMarkerPath} version=${PKG_VERSION}`);
+    // The version marker is NOT written here. It is stamped at the very end of a
+    // fully-successful install (after plugin registration and every throwing
+    // step), so an aborted upgrade cannot leave a marker that reports success it
+    // did not complete. Task 1462.
     console.log(`  Deployed to ${INSTALL_DIR}`);
 }
 // register the local + external Claude Code plugins after the
@@ -4983,6 +4997,22 @@ const PLATFORM_HEADER = `[create-maxy] platform=${PLATFORM} arch=${process.arch}
 console.log(PLATFORM_HEADER);
 console.log(`[create-maxy] log=${LOG_FILE} persist=${PERSIST_DIR}`);
 initLogging();
+// Pin the process CWD before any step runs. npx inherits the operator's shell
+// CWD; if they invoked the upgrade from inside the install tree (e.g. `cd
+// ~/.<brand>/platform && npx ...`), deployPayload()'s rmSync deletes that live
+// CWD mid-run and every subprocess spawned afterward inherits a deleted inode
+// (JVM `getcwd() failed` during the Neo4j auth reset; Bun ENOENT during plugin
+// registration). HOME is never wiped — deployPayload only rmSync's subdirs of
+// INSTALL_DIR — so it is a safe anchor; fall back to "/" if the HOME chdir
+// throws. Task 1462.
+try {
+    process.chdir(process.env.HOME ?? "/");
+}
+catch {
+    process.chdir("/");
+}
+console.log(`  [create-maxy] cwd-pinned to=${process.cwd()}`);
+logFile(`[create-maxy] cwd-pinned to=${process.cwd()}`);
 console.log("================================================================");
 console.log(`  ${BRAND.productName} — ${BRAND.tagline}.  (${BRAND.hostname} v${PKG_VERSION})`);
 console.log("================================================================");
@@ -5066,6 +5096,15 @@ try {
     // (the reboot-loop this defends against). A partial/failed install exits
     // before this point and never writes the drop-in.
     configureHardwareWatchdog();
+    // Stamp the version marker as the last thing a fully-successful install does.
+    // Every throwing step (plugin registration, service install, account setup)
+    // runs before this, so an aborted upgrade exits via the catch below and never
+    // writes it — the running platform never reports a version it did not finish
+    // installing. platform/config is excluded from the Task 848 freeze above, so
+    // it is still writable here. Task 1462.
+    const versionMarkerPath = join(INSTALL_DIR, "platform/config", `.${BRAND.hostname}-version`);
+    writeFileSync(versionMarkerPath, PKG_VERSION, "utf-8");
+    console.log(`  [install] version-marker written path=${versionMarkerPath} version=${PKG_VERSION}`);
     console.log("");
     console.log("================================================================");
     console.log("");

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@rubytech/create-maxy-code",
-  "version": "0.1.412",
+  "version": "0.1.414",
   "description": "Install Maxy — AI for Productive People",
   "bin": {
     "create-maxy-code": "./dist/index.js"

package/payload/platform/plugins/admin/skills/platform-architecture/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: platform-architecture
 description: Use when grounding any documented-surface claim about what Maxy ships — plugins, skills, specialists, install/deploy flows, internals. This is the install catalogue, not evidence of what is enabled on the current account. For install state on this account, call `capabilities-here`; for documented surface, cite the `Source:` URL inline.
-content-hash: sha256:3e8c5b6a28d0ca8c9bcbbb802165d8b2fffcb1af2531353bda360e8b7eb964f6
+content-hash: sha256:9b227cf8ab845f23cb1899d5b2ac2581cfac3aae772715bf02d288ee93d8fbc4
 brand: maxy-code
 product-name: Maxy
 ---
@@ -532,7 +532,9 @@ The operator wants this for two surfaces: the account graph and the account file
 
 The `memory` plugin gives the admin session access to a sub-account's knowledge graph. Its tools whose read or write is scoped solely by the account — search, lookup, write, update, edit, delete, edges, attachments, reports, conversation history, ingest, and graph maintenance — take an optional target. Omit it and the tool acts on the session's own account, exactly as before; pass a sub-account and a house-scoped admin session reads or writes that account's subgraph instead; any other session that names a target is refused.
 
-A few memory tools do **not** take a target. `profile-read`/`update`/`delete` and `session-compact` are keyed to the caller's own identity (the operator's user, and the live session) rather than only the account, so re-pointing the account alone would act on the wrong record; cross-account for these is a separate, later piece of work. `graph-prune-denylist-*` and `memory-ingest-extract` are not account-scoped at all (a shared deny-list and a temporary staging step), so a target would mean nothing. These stay on the session's own account.
+`profile-read`/`update`/`delete` also take a target. They are keyed to a user as well as the account, so cross-account they cannot use the caller's own user (a house operator has no record inside a sub-account); instead they resolve the sub-account's owner — the single admin identity seeded with every account — and act on that owner's profile. A house-scoped session can therefore read or set a sub-account's profile (its owner's name, role, timezone, locale, and preferences); a target with no owner is refused rather than writing a stray record. Setting a sub-account owner's email or telephone this way is not available yet.
+
+A few memory tools do **not** take a target. `session-compact` acts on the caller's own live session, which belongs to the account the operator is in, so pointing it at a sub-account has no meaning. `graph-prune-denylist-*` and `memory-ingest-extract` are not account-scoped at all (a shared deny-list and a temporary staging step), so a target would mean nothing. These stay on the session's own account.
 
 ## Filesystem
 
@@ -1612,7 +1614,7 @@ People entries (`:Person`) are deliberately excluded from this dual-summary syst
 
 ## Working across accounts
 
-If you run Maxy as the house account — the operator account that manages sub-accounts — you can point a memory action at one of your sub-accounts instead of your own. Name the account when you ask, for example "search Anneke's account for the roofing quote" or "add this note to the Jones account." Most memory actions honour this: search, read, write, edit, delete, reports, and conversation history. Profile actions ("what do you know about me") stay on your own account for now.
+If you run Maxy as the house account — the operator account that manages sub-accounts — you can point a memory action at one of your sub-accounts instead of your own. Name the account when you ask, for example "search Anneke's account for the roofing quote" or "add this note to the Jones account." Most memory actions honour this: search, read, write, edit, delete, reports, and conversation history. Profile actions honour it too — you can read and set a sub-account's profile (its owner's name, role, timezone, locale, and preferences) from the house account, for example "set the Jones account's name to Jane"; the profile is attributed to that sub-account's owner, so there is no orphan record and no PIN is needed. Setting a sub-account owner's email or telephone from the house account is not available yet. Compacting a conversation always acts on the session you are in, so it cannot be pointed at a sub-account.
 
 Leave the account out and nothing changes — the action runs on your own account exactly as before. Only the house account can do this. A sub-account session that tries to reach another account is refused, and naming an account that does not exist is refused too. Sub-accounts stay fully isolated from each other.
 

package/payload/platform/plugins/docs/references/cross-account-authority.md

@@ -10,7 +10,9 @@ The operator wants this for two surfaces: the account graph and the account file
 
 The `memory` plugin gives the admin session access to a sub-account's knowledge graph. Its tools whose read or write is scoped solely by the account — search, lookup, write, update, edit, delete, edges, attachments, reports, conversation history, ingest, and graph maintenance — take an optional target. Omit it and the tool acts on the session's own account, exactly as before; pass a sub-account and a house-scoped admin session reads or writes that account's subgraph instead; any other session that names a target is refused.
 
-A few memory tools do **not** take a target. `profile-read`/`update`/`delete` and `session-compact` are keyed to the caller's own identity (the operator's user, and the live session) rather than only the account, so re-pointing the account alone would act on the wrong record; cross-account for these is a separate, later piece of work. `graph-prune-denylist-*` and `memory-ingest-extract` are not account-scoped at all (a shared deny-list and a temporary staging step), so a target would mean nothing. These stay on the session's own account.
+`profile-read`/`update`/`delete` also take a target. They are keyed to a user as well as the account, so cross-account they cannot use the caller's own user (a house operator has no record inside a sub-account); instead they resolve the sub-account's owner — the single admin identity seeded with every account — and act on that owner's profile. A house-scoped session can therefore read or set a sub-account's profile (its owner's name, role, timezone, locale, and preferences); a target with no owner is refused rather than writing a stray record. Setting a sub-account owner's email or telephone this way is not available yet.
+
+A few memory tools do **not** take a target. `session-compact` acts on the caller's own live session, which belongs to the account the operator is in, so pointing it at a sub-account has no meaning. `graph-prune-denylist-*` and `memory-ingest-extract` are not account-scoped at all (a shared deny-list and a temporary staging step), so a target would mean nothing. These stay on the session's own account.
 
 ## Filesystem
 

package/payload/platform/plugins/docs/references/memory-guide.md

@@ -158,7 +158,7 @@ People entries (`:Person`) are deliberately excluded from this dual-summary syst
 
 ## Working across accounts
 
-If you run {{productName}} as the house account — the operator account that manages sub-accounts — you can point a memory action at one of your sub-accounts instead of your own. Name the account when you ask, for example "search Anneke's account for the roofing quote" or "add this note to the Jones account." Most memory actions honour this: search, read, write, edit, delete, reports, and conversation history. Profile actions ("what do you know about me") stay on your own account for now.
+If you run {{productName}} as the house account — the operator account that manages sub-accounts — you can point a memory action at one of your sub-accounts instead of your own. Name the account when you ask, for example "search Anneke's account for the roofing quote" or "add this note to the Jones account." Most memory actions honour this: search, read, write, edit, delete, reports, and conversation history. Profile actions honour it too — you can read and set a sub-account's profile (its owner's name, role, timezone, locale, and preferences) from the house account, for example "set the Jones account's name to Jane"; the profile is attributed to that sub-account's owner, so there is no orphan record and no PIN is needed. Setting a sub-account owner's email or telephone from the house account is not available yet. Compacting a conversation always acts on the session you are in, so it cannot be pointed at a sub-account.
 
 Leave the account out and nothing changes — the action runs on your own account exactly as before. Only the house account can do this. A sub-account session that tries to reach another account is refused, and naming an account that does not exist is refused too. Sub-accounts stay fully isolated from each other.
 

package/payload/platform/plugins/memory/PLUGIN.md

@@ -187,9 +187,11 @@ Writes targeting `:Person`, `:UserProfile`, `:AdminUser`, `:Organization`, `:Loc
 
 ## Cross-account access (house admin) — `targetAccountId`
 
-The memory tools whose Neo4j read/write is scoped **solely** by `accountId` accept an optional `targetAccountId`. A house-scoped `role:admin` session sets it to read or write a **sub-account's** subgraph instead of its own; omitting it is byte-identical to the pre-existing own-account behaviour. Only a house-scoped session may set it: a sub-account or public session that passes `targetAccountId` is rejected `cross-account-denied`, and a house session naming an account that does not exist on this install is rejected `cross-account-invalid-target`. Resolution runs through the shared `resolveEffectiveAccount` primitive — there is no house fallback and no local re-implementation. Each call that sets `targetAccountId` emits one `[xacct] op=call tool=<t> caller=<own8> target=<tgt8> houseScope=<bool> decision=<allow|deny> reason=<…>` line before the graph call, and the tool's own `[memory-<t>] [<accountId>]` line prints the resolved (target) id as a wrong-subgraph cross-check.
+The memory tools whose Neo4j read/write re-scopes on the resolved account accept an optional `targetAccountId`. A house-scoped `role:admin` session sets it to read or write a **sub-account's** subgraph instead of its own; omitting it is byte-identical to the pre-existing own-account behaviour. Only a house-scoped session may set it: a sub-account or public session that passes `targetAccountId` is rejected `cross-account-denied`, and a house session naming an account that does not exist on this install is rejected `cross-account-invalid-target`. Resolution runs through the shared `resolveEffectiveAccount` primitive — there is no house fallback and no local re-implementation. Each call that sets `targetAccountId` emits one `[xacct] op=call tool=<t> caller=<own8> target=<tgt8> houseScope=<bool> decision=<allow|deny> reason=<…>` line before the graph call, and the tool's own `[memory-<t>] [<accountId>]` line prints the resolved (target) id as a wrong-subgraph cross-check.
 
-Tools that do **not** take `targetAccountId` fall into three groups. **Not account-scoped:** `image-fetch` fetches image bytes by URL; `graph-prune-denylist-add/remove/list` mutate a brand-global deny-list; `memory-ingest-extract` stages a temp file — none read or write a sub-account subgraph. **Bound to a caller constant the parameter cannot re-scope:** `profile-read/update/delete` key on the operator's `userId`, and `session-compact` keys on the caller's live session — cross-account support for these is deferred (it needs `userId`/session re-scoping, a separate design question). **Scheduled, not interactive:** the dream-cycle **cron** (`lib/dream-cycle/*`) takes its account from the scheduler context, not a tool argument; only the interactive `memory-dream-run` tool is house-targetable. These tools keep their own-account no-account guard.
+`profile-read/update/delete` also take `targetAccountId`. They key on `userId` as well as `accountId`, so cross-account they cannot use the caller's boot `USER_ID` (a house operator has no node in the sub-account subgraph). Instead they resolve the target sub-account's **owner** `AdminUser` — the single identity seeded per account (`role:"owner"`, one per account) — and attribute the read/write to it, emitting `[xacct] op=identity tool=profile-* target=<sub8> resolved-userId=<owner8>`. A target with no owner `AdminUser` is rejected loudly (never a wrong-identity write). `profile-update` bootstraps the owner's `UserProfile` on this path so a preference-only write lands. This covers preferences and every `profileFields` value (name via `givenName`/`familyName`, `role`, `timezone`, `locale`, `expertise`); no `Person` node or PIN is required. Setting `personFields` identity (email/telephone → the owner `Person`) cross-account is deferred and keeps loud-failing until then.
+
+Tools that do **not** take `targetAccountId` fall into three groups. **Not account-scoped:** `image-fetch` fetches image bytes by URL; `graph-prune-denylist-add/remove/list` mutate a brand-global deny-list; `memory-ingest-extract` stages a temp file — none read or write a sub-account subgraph. **Bound to the caller's own live session:** `session-compact` compacts the caller's `SESSION_ID` Conversation, which belongs to the house account the operator sits in — re-scoping `accountId` to a sub-account matches nothing and "compact a sub-account's live session" has no referent. **Scheduled, not interactive:** the dream-cycle **cron** (`lib/dream-cycle/*`) takes its account from the scheduler context, not a tool argument; only the interactive `memory-dream-run` tool is house-targetable. These tools keep their own-account no-account guard.
 
 ## Graph Hygiene
 

package/payload/platform/plugins/memory/mcp/dist/index.js

@@ -41,6 +41,7 @@ import { profileRead } from "./tools/profile-read.js";
 import { memoryBrainCaptureRecent } from "./tools/memory-brain-capture-recent.js";
 import { profileUpdate } from "./tools/profile-update.js";
 import { profileDelete } from "./tools/profile-delete.js";
+import { resolveOwnerUserId } from "./lib/resolve-owner-userid.js";
 import { graphPruneDenylistAdd } from "./tools/graph-prune-denylist-add.js";
 import { graphPruneDenylistList } from "./tools/graph-prune-denylist-list.js";
 import { graphPruneDenylistRemove } from "./tools/graph-prune-denylist-remove.js";
@@ -104,6 +105,37 @@ const resolveToolAccount = makeResolveToolAccount({
 // Single source for the operator-facing targetAccountId description — the LLM
 // reads this verbatim, so it must not drift across the 35 targetable tools.
 const XACCT_DESC = "House-scoped admin only: operate on the named sub-account subgraph instead of your own. Only a house-scoped session may set this; a non-house session that sets it is rejected.";
+// Boot account, captured before the tool handlers shadow `accountId` with the
+// resolved (possibly cross-account) id. A resolved id != this is a cross-account
+// call (the resolver only returns a target for a house-authorised session).
+const BOOT_ACCOUNT_ID = accountId;
+async function resolveProfileIdentity(toolName, crossAccount, resolvedAccountId, callerUserId) {
+    if (crossAccount) {
+        const owner = await resolveOwnerUserId(resolvedAccountId);
+        if (!owner) {
+            return {
+                reject: {
+                    content: [{
+                            type: "text",
+                            text: `${toolName} failed: target account ${resolvedAccountId.slice(0, 8)}… has no owner AdminUser to attribute the profile to — its graph root is unprovisioned (see Task 1359 seedAccountGraphRoot).`,
+                        }],
+                    isError: true,
+                },
+            };
+        }
+        process.stderr.write(`[xacct] op=identity tool=${toolName} target=${resolvedAccountId.slice(0, 8)} resolved-userId=${owner.slice(0, 8)}\n`);
+        return { userId: owner };
+    }
+    if (!callerUserId) {
+        return {
+            reject: {
+                content: [{ type: "text", text: `${toolName} requires an authenticated admin session with userId` }],
+                isError: true,
+            },
+        };
+    }
+    return { userId: callerUserId };
+}
 // Load the markdown schema sidecar once at startup. Every memory-write call
 // reads its required-property and synonym maps. If loading fails we throw —
 // a memory server running with a broken schema is worse than one that fails
@@ -2170,18 +2202,20 @@ if (!readOnly) {
             .describe("Operator-identity fields written to the OWNS-bound Person. Use canonical `telephone` (NOT `phone` — that is the schema synonym, not the canonical name). Tool throws if the AdminUser-OWNS-Person edge is missing rather than silently no-op."),
         mergeSourceIds: z.array(z.string()).optional()
             .describe("For mode 'merge': preferenceIds of sources to combine into this preference"),
-    }, async ({ category, key, value, source, mode, sessionId, profileFields, personFields, mergeSourceIds }) => {
-        const scoped = resolveToolAccount("profile-update", undefined);
+        targetAccountId: z.string().optional().describe(XACCT_DESC),
+    }, async ({ category, key, value, source, mode, sessionId, profileFields, personFields, mergeSourceIds, targetAccountId }) => {
+        const scoped = resolveToolAccount("profile-update", targetAccountId);
         if ("reject" in scoped)
             return scoped.reject;
         const accountId = scoped.accountId;
+        const crossAccount = accountId !== BOOT_ACCOUNT_ID;
         try {
-            if (!userId) {
-                return { content: [{ type: "text", text: "profile-update requires an authenticated admin session with userId" }], isError: true };
-            }
+            const ident = await resolveProfileIdentity("profile-update", crossAccount, accountId, userId);
+            if ("reject" in ident)
+                return ident.reject;
             const result = await profileUpdate({
                 accountId,
-                userId,
+                userId: ident.userId,
                 category,
                 key,
                 value,
@@ -2191,6 +2225,7 @@ if (!readOnly) {
                 profileFields: profileFields,
                 personFields,
                 mergeSourceIds,
+                bootstrapProfile: crossAccount,
             });
             return {
                 content: [{
@@ -2213,16 +2248,18 @@ if (!readOnly) {
         category: z.enum(["communication", "scheduling", "decision", "workflow", "content", "interaction"])
             .describe("Preference category"),
         key: z.string().describe("Preference key to delete"),
-    }, async ({ category, key }) => {
-        const scoped = resolveToolAccount("profile-delete", undefined);
+        targetAccountId: z.string().optional().describe(XACCT_DESC),
+    }, async ({ category, key, targetAccountId }) => {
+        const scoped = resolveToolAccount("profile-delete", targetAccountId);
         if ("reject" in scoped)
             return scoped.reject;
         const accountId = scoped.accountId;
+        const crossAccount = accountId !== BOOT_ACCOUNT_ID;
         try {
-            if (!userId) {
-                return { content: [{ type: "text", text: "profile-delete requires an authenticated admin session with userId" }], isError: true };
-            }
-            const result = await profileDelete({ accountId, userId, category, key });
+            const ident = await resolveProfileIdentity("profile-delete", crossAccount, accountId, userId);
+            if ("reject" in ident)
+                return ident.reject;
+            const result = await profileDelete({ accountId, userId: ident.userId, category, key });
             return {
                 content: [{
                         type: "text",
@@ -2249,16 +2286,18 @@ if (!readOnly) {
         "Use detail=true when the owner asks 'what do you know about me?' or when reviewing memory accuracy.", {
         detail: z.boolean().optional().describe("When true, returns per-preference confidence, source, evidence trail, and memory statistics. " +
             "Default false returns a compact summary for system prompt injection."),
-    }, async ({ detail }) => {
-        const scoped = resolveToolAccount("profile-read", undefined);
+        targetAccountId: z.string().optional().describe(XACCT_DESC),
+    }, async ({ detail, targetAccountId }) => {
+        const scoped = resolveToolAccount("profile-read", targetAccountId);
         if ("reject" in scoped)
             return scoped.reject;
         const accountId = scoped.accountId;
+        const crossAccount = accountId !== BOOT_ACCOUNT_ID;
         try {
-            if (!userId) {
-                return { content: [{ type: "text", text: "profile-read requires an authenticated admin session with userId" }], isError: true };
-            }
-            const result = await profileRead({ accountId, userId, detail: detail ?? false });
+            const ident = await resolveProfileIdentity("profile-read", crossAccount, accountId, userId);
+            if ("reject" in ident)
+                return ident.reject;
+            const result = await profileRead({ accountId, userId: ident.userId, detail: detail ?? false });
             return {
                 content: [{ type: "text", text: result.summary }],
             };