@rubytech/create-maxy-code 0.1.411 → 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.411",
+  "version": "0.1.414",
   "description": "Install Maxy — AI for Productive People",
   "bin": {
     "create-maxy-code": "./dist/index.js"

package/payload/platform/lib/account-scope/dist/index.d.ts

@@ -0,0 +1,27 @@
+export type EffectiveAccount = {
+    accountId: string;
+} | {
+    reject: "cross-account-denied" | "cross-account-invalid-target";
+};
+/**
+ * Resolve the account a call acts on. Fail-closed: only a house-scoped session
+ * may set `targetAccountId`, and only to a valid account. There is no house
+ * fallback — an unscoped session that names a target is denied, never silently
+ * downgraded to its own account.
+ *
+ * `isValidAccountId` is injected (required, no default): the UI passes its
+ * fs-backed `isValidAccountId`; the `filesystem` plugin passes a check over
+ * `enumerateValidAccountIds`. Keeping validity injected is what lets this
+ * module stay pure.
+ */
+export declare function resolveEffectiveAccountCore(input: {
+    ownAccountId: string;
+    houseScope: string | null;
+    targetAccountId?: string | null;
+}, isValidAccountId: (id: string) => boolean): EffectiveAccount;
+/**
+ * Boot-reader that consumers import to learn their house scope from the spawn
+ * env. An empty value reads as null — a non-house session carries no scope.
+ */
+export declare function readHouseAdminScope(env?: NodeJS.ProcessEnv): string | null;
+//# sourceMappingURL=index.d.ts.map

package/payload/platform/lib/account-scope/dist/index.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"index.d.ts","sourceRoot":"","sources":["../src/index.ts"],"names":[],"mappings":"AAUA,MAAM,MAAM,gBAAgB,GACxB;IAAE,SAAS,EAAE,MAAM,CAAA;CAAE,GACrB;IAAE,MAAM,EAAE,sBAAsB,GAAG,8BAA8B,CAAA;CAAE,CAAC;AAExE;;;;;;;;;;GAUG;AACH,wBAAgB,2BAA2B,CACzC,KAAK,EAAE;IAAE,YAAY,EAAE,MAAM,CAAC;IAAC,UAAU,EAAE,MAAM,GAAG,IAAI,CAAC;IAAC,eAAe,CAAC,EAAE,MAAM,GAAG,IAAI,CAAA;CAAE,EAC3F,gBAAgB,EAAE,CAAC,EAAE,EAAE,MAAM,KAAK,OAAO,GACxC,gBAAgB,CAMlB;AAED;;;GAGG;AACH,wBAAgB,mBAAmB,CAAC,GAAG,GAAE,MAAM,CAAC,UAAwB,GAAG,MAAM,GAAG,IAAI,CAEvF"}

package/payload/platform/lib/account-scope/dist/index.js

@@ -0,0 +1,33 @@
+"use strict";
+Object.defineProperty(exports, "__esModule", { value: true });
+exports.resolveEffectiveAccountCore = resolveEffectiveAccountCore;
+exports.readHouseAdminScope = readHouseAdminScope;
+/**
+ * Resolve the account a call acts on. Fail-closed: only a house-scoped session
+ * may set `targetAccountId`, and only to a valid account. There is no house
+ * fallback — an unscoped session that names a target is denied, never silently
+ * downgraded to its own account.
+ *
+ * `isValidAccountId` is injected (required, no default): the UI passes its
+ * fs-backed `isValidAccountId`; the `filesystem` plugin passes a check over
+ * `enumerateValidAccountIds`. Keeping validity injected is what lets this
+ * module stay pure.
+ */
+function resolveEffectiveAccountCore(input, isValidAccountId) {
+    const { ownAccountId, houseScope, targetAccountId } = input;
+    if (!targetAccountId)
+        return { accountId: ownAccountId };
+    if (!houseScope)
+        return { reject: "cross-account-denied" };
+    if (!isValidAccountId(targetAccountId))
+        return { reject: "cross-account-invalid-target" };
+    return { accountId: targetAccountId };
+}
+/**
+ * Boot-reader that consumers import to learn their house scope from the spawn
+ * env. An empty value reads as null — a non-house session carries no scope.
+ */
+function readHouseAdminScope(env = process.env) {
+    return env.HOUSE_ADMIN_SCOPE ? env.HOUSE_ADMIN_SCOPE : null;
+}
+//# sourceMappingURL=index.js.map

package/payload/platform/lib/account-scope/dist/index.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"index.js","sourceRoot":"","sources":["../src/index.ts"],"names":[],"mappings":";;AAyBA,kEASC;AAMD,kDAEC;AA5BD;;;;;;;;;;GAUG;AACH,SAAgB,2BAA2B,CACzC,KAA2F,EAC3F,gBAAyC;IAEzC,MAAM,EAAE,YAAY,EAAE,UAAU,EAAE,eAAe,EAAE,GAAG,KAAK,CAAC;IAC5D,IAAI,CAAC,eAAe;QAAE,OAAO,EAAE,SAAS,EAAE,YAAY,EAAE,CAAC;IACzD,IAAI,CAAC,UAAU;QAAE,OAAO,EAAE,MAAM,EAAE,sBAAsB,EAAE,CAAC;IAC3D,IAAI,CAAC,gBAAgB,CAAC,eAAe,CAAC;QAAE,OAAO,EAAE,MAAM,EAAE,8BAA8B,EAAE,CAAC;IAC1F,OAAO,EAAE,SAAS,EAAE,eAAe,EAAE,CAAC;AACxC,CAAC;AAED;;;GAGG;AACH,SAAgB,mBAAmB,CAAC,MAAyB,OAAO,CAAC,GAAG;IACtE,OAAO,GAAG,CAAC,iBAAiB,CAAC,CAAC,CAAC,GAAG,CAAC,iBAAiB,CAAC,CAAC,CAAC,IAAI,CAAC;AAC9D,CAAC"}

package/payload/platform/lib/account-scope/src/index.ts

@@ -0,0 +1,43 @@
+// account-scope — the single fail-closed cross-account resolver.
+//
+// Task 1440 landed this logic inline in
+// platform/ui/app/lib/claude-agent/account.ts. Task 1458 relocates the two
+// pure primitives here so BOTH the UI lib (account.ts, which re-exports them)
+// and MCP plugins (the `filesystem` plugin) import ONE definition — "one
+// resolver, no drift", the same privilege-boundary discipline as the 1383/1385
+// account-manager escalation. This module is pure: no filesystem access, no
+// throw at module load, so it is safe to import into an MCP server that boots
+// with empty env during plugin-system `tools/list` enumeration.
+export type EffectiveAccount =
+  | { accountId: string }
+  | { reject: "cross-account-denied" | "cross-account-invalid-target" };
+
+/**
+ * Resolve the account a call acts on. Fail-closed: only a house-scoped session
+ * may set `targetAccountId`, and only to a valid account. There is no house
+ * fallback — an unscoped session that names a target is denied, never silently
+ * downgraded to its own account.
+ *
+ * `isValidAccountId` is injected (required, no default): the UI passes its
+ * fs-backed `isValidAccountId`; the `filesystem` plugin passes a check over
+ * `enumerateValidAccountIds`. Keeping validity injected is what lets this
+ * module stay pure.
+ */
+export function resolveEffectiveAccountCore(
+  input: { ownAccountId: string; houseScope: string | null; targetAccountId?: string | null },
+  isValidAccountId: (id: string) => boolean,
+): EffectiveAccount {
+  const { ownAccountId, houseScope, targetAccountId } = input;
+  if (!targetAccountId) return { accountId: ownAccountId };
+  if (!houseScope) return { reject: "cross-account-denied" };
+  if (!isValidAccountId(targetAccountId)) return { reject: "cross-account-invalid-target" };
+  return { accountId: targetAccountId };
+}
+
+/**
+ * Boot-reader that consumers import to learn their house scope from the spawn
+ * env. An empty value reads as null — a non-house session carries no scope.
+ */
+export function readHouseAdminScope(env: NodeJS.ProcessEnv = process.env): string | null {
+  return env.HOUSE_ADMIN_SCOPE ? env.HOUSE_ADMIN_SCOPE : null;
+}

package/payload/platform/lib/account-scope/tsconfig.json

@@ -0,0 +1,5 @@
+{
+  "extends": "../../tsconfig.base.json",
+  "compilerOptions": { "outDir": "dist", "rootDir": "src" },
+  "include": ["src"]
+}

package/payload/platform/package.json

@@ -6,8 +6,8 @@
     "services/*"
   ],
   "scripts": {
-    "build": "tsc -p lib/models/tsconfig.json && tsc -p lib/mcp-stderr-tee/tsconfig.json && tsc -p lib/mcp-spawn-tee/tsconfig.json && tsc -p lib/mcp-lifeline/tsconfig.json && tsc -p lib/mcp-eager/tsconfig.json && tsc -p lib/account-enumeration/tsconfig.json && tsc -p lib/graph-write/tsconfig.json && tsc -p lib/embed-client/tsconfig.json && tsc -p lib/graph-mcp/tsconfig.json && tsc -p lib/graph-trash/tsconfig.json && tsc -p lib/admin-conversation-purge/tsconfig.json && tsc -p lib/graph-search/tsconfig.json && tsc -p lib/graph-style/tsconfig.json && tsc -p lib/device-url/tsconfig.json && tsc -p lib/brand-templating/tsconfig.json && tsc -p lib/entitlement/tsconfig.json && tsc -p lib/task-secrets/tsconfig.json && tsc -p lib/admins-write/tsconfig.json && tsc -p lib/admin-access-password/tsconfig.json && tsc -p lib/persistent-components/tsconfig.json && tsc -p lib/require-port-env/tsconfig.json && tsc -p lib/aeo-llms-txt-writer/tsconfig.json && tsc -p lib/obsidian-parser/tsconfig.json && tsc -p services/claude-session-manager/tsconfig.json && tsc -p services/whatsapp-channel/tsconfig.json && tsc -p services/webchat-channel/tsconfig.json && NODE_OPTIONS='--max-old-space-size=8192' tsc -b plugins/*/mcp/tsconfig.json",
-    "build:lib": "tsc -p lib/models/tsconfig.json && tsc -p lib/mcp-stderr-tee/tsconfig.json && tsc -p lib/mcp-spawn-tee/tsconfig.json && tsc -p lib/mcp-lifeline/tsconfig.json && tsc -p lib/mcp-eager/tsconfig.json && tsc -p lib/account-enumeration/tsconfig.json && tsc -p lib/graph-write/tsconfig.json && tsc -p lib/embed-client/tsconfig.json && tsc -p lib/graph-mcp/tsconfig.json && tsc -p lib/graph-trash/tsconfig.json && tsc -p lib/admin-conversation-purge/tsconfig.json && tsc -p lib/graph-search/tsconfig.json && tsc -p lib/graph-style/tsconfig.json && tsc -p lib/device-url/tsconfig.json && tsc -p lib/brand-templating/tsconfig.json && tsc -p lib/entitlement/tsconfig.json && tsc -p lib/task-secrets/tsconfig.json && tsc -p lib/admins-write/tsconfig.json && tsc -p lib/admin-access-password/tsconfig.json && tsc -p lib/persistent-components/tsconfig.json && tsc -p lib/require-port-env/tsconfig.json && tsc -p lib/aeo-llms-txt-writer/tsconfig.json && tsc -p lib/obsidian-parser/tsconfig.json",
+    "build": "tsc -p lib/models/tsconfig.json && tsc -p lib/mcp-stderr-tee/tsconfig.json && tsc -p lib/mcp-spawn-tee/tsconfig.json && tsc -p lib/mcp-lifeline/tsconfig.json && tsc -p lib/mcp-eager/tsconfig.json && tsc -p lib/account-enumeration/tsconfig.json && tsc -p lib/account-scope/tsconfig.json && tsc -p lib/graph-write/tsconfig.json && tsc -p lib/embed-client/tsconfig.json && tsc -p lib/graph-mcp/tsconfig.json && tsc -p lib/graph-trash/tsconfig.json && tsc -p lib/admin-conversation-purge/tsconfig.json && tsc -p lib/graph-search/tsconfig.json && tsc -p lib/graph-style/tsconfig.json && tsc -p lib/device-url/tsconfig.json && tsc -p lib/brand-templating/tsconfig.json && tsc -p lib/entitlement/tsconfig.json && tsc -p lib/task-secrets/tsconfig.json && tsc -p lib/admins-write/tsconfig.json && tsc -p lib/admin-access-password/tsconfig.json && tsc -p lib/persistent-components/tsconfig.json && tsc -p lib/require-port-env/tsconfig.json && tsc -p lib/aeo-llms-txt-writer/tsconfig.json && tsc -p lib/obsidian-parser/tsconfig.json && tsc -p services/claude-session-manager/tsconfig.json && tsc -p services/whatsapp-channel/tsconfig.json && tsc -p services/webchat-channel/tsconfig.json && NODE_OPTIONS='--max-old-space-size=8192' tsc -b plugins/*/mcp/tsconfig.json",
+    "build:lib": "tsc -p lib/models/tsconfig.json && tsc -p lib/mcp-stderr-tee/tsconfig.json && tsc -p lib/mcp-spawn-tee/tsconfig.json && tsc -p lib/mcp-lifeline/tsconfig.json && tsc -p lib/mcp-eager/tsconfig.json && tsc -p lib/account-enumeration/tsconfig.json && tsc -p lib/account-scope/tsconfig.json && tsc -p lib/graph-write/tsconfig.json && tsc -p lib/embed-client/tsconfig.json && tsc -p lib/graph-mcp/tsconfig.json && tsc -p lib/graph-trash/tsconfig.json && tsc -p lib/admin-conversation-purge/tsconfig.json && tsc -p lib/graph-search/tsconfig.json && tsc -p lib/graph-style/tsconfig.json && tsc -p lib/device-url/tsconfig.json && tsc -p lib/brand-templating/tsconfig.json && tsc -p lib/entitlement/tsconfig.json && tsc -p lib/task-secrets/tsconfig.json && tsc -p lib/admins-write/tsconfig.json && tsc -p lib/admin-access-password/tsconfig.json && tsc -p lib/persistent-components/tsconfig.json && tsc -p lib/require-port-env/tsconfig.json && tsc -p lib/aeo-llms-txt-writer/tsconfig.json && tsc -p lib/obsidian-parser/tsconfig.json",
     "gen:canonical-tools": "node scripts/generate-canonical-tool-names.mjs",
     "build:memory": "tsc -p plugins/memory/mcp/tsconfig.json",
     "build:contacts": "tsc -p plugins/contacts/mcp/tsconfig.json",

package/payload/platform/plugins/.claude-plugin/marketplace.json

@@ -54,6 +54,11 @@
       "source": "./email",
       "version": "0.1.0"
     },
+    {
+      "name": "filesystem",
+      "source": "./filesystem",
+      "version": "0.1.0"
+    },
     {
       "name": "graph",
       "source": "./graph",

package/payload/platform/plugins/admin/hooks/lib/maxy-mcp-plugins.txt

@@ -4,6 +4,7 @@ browser
 connector
 contacts
 email
+filesystem
 graph
 graph-viewer
 joblogic

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:69d2ec47598e75fac6f763994a077fd39ccda77767ddb90404dac2d556f5791c
+content-hash: sha256:9b227cf8ab845f23cb1899d5b2ac2581cfac3aae772715bf02d288ee93d8fbc4
 brand: maxy-code
 product-name: Maxy
 ---
@@ -516,6 +516,36 @@ A third layer closes the same gap from the platform side: when `claude-agent.ts`
 
 **Boot-smoke as publish-time gate.** The memory MCP carries `scripts/boot-smoke.sh` that spawns `dist/index.js` with stub env, sleeps 2s, asserts `kill -0 <pid>`, and reports `[boot-smoke] memory ok|FAILED tail=<n-lines>`. Wired to `prepublish` in `plugins/memory/mcp/package.json`. The pattern is propagatable to other plugin MCPs — it's deliberately not generalised yet because each plugin's stub-env requirements differ (memory needs ACCOUNT_ID + PLATFORM_ROOT + NEO4J_URI + SESSION_ID; others differ).
 
+---
+# House-Admin Cross-Account Authority
+Source: https://docs.getmaxy.com/cross-account-authority.md
+
+# House-admin cross-account authority
+
+The house account is the operator-owned account that runs the admin assistant. Sub-accounts are isolated: each one's tools read and write only that account's data, which is what keeps tenants separate.
+
+By default the admin assistant is scoped the same way — it acts on the house account. Cross-account authority lets a house-scoped admin session act on a named sub-account by passing that account as a target, while every other session (public visitors, a session already scoped to a sub-account, background specialists) is refused. The refusal is fail-closed: a session that is not house-scoped and names a target is denied, never quietly redirected to its own account.
+
+The operator wants this for two surfaces: the account graph and the account filesystem. Each is a separate adoption; a coverage ledger tracks them and a background check confirms neither silently regresses.
+
+## Memory (graph)
+
+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.
+
+`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
+
+The `filesystem` plugin gives the admin session direct access to the account working directory (`data/accounts/<id>/`) — `SOUL.md`, generated documents, screenshots, arbitrary files. It exists because the native file tools (Read, Write, Edit, and the shell) are locked to the session's own account and cannot take a target. Its six tools are `file-read`, `file-write`, `file-edit`, `file-list`, `file-glob`, and `file-grep`.
+
+Omit the target and each tool acts on the session's own account, exactly like the native tools. Pass a sub-account as the target and a house-scoped admin session reads or writes that account's files instead; any other session that names a target is refused. Every path is confined to the resolved account directory — a path that climbs out with `../`, an absolute path outside the account root, or a symlink pointing away is rejected before anything is read or written, so the tools can never reach another account or the platform's own files.
+
+## Signals
+
+A standing background check reconciles live sessions against the account roles and raises an alarm if any session still holds house authority for an account that is no longer the house account, so a stale grant cannot sit unnoticed. Each cross-account tool call also records its decision — who called, which account it targeted, whether it was allowed, and why — before it touches the graph or disk, and a rejected filesystem path escape is recorded on its own line. In normal operation neither an allowed cross-account call from a non-house session nor a path escape ever appears.
+
 ---
 # Install Overview
 Source: https://docs.getmaxy.com/install.md
@@ -1582,6 +1612,12 @@ If you want to write the public summary yourself — for instance, because the a
 
 People entries (`:Person`) are deliberately excluded from this dual-summary system. Notes about contacts are private by definition and never get a public-facing form.
 
+## 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 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.
+
 ## Privacy
 
 All memory is stored on your local Raspberry Pi. The Neo4j database never leaves your network. Maxy does not sync memory to any cloud service or third party.

package/payload/platform/plugins/business-assistant/skills/e-sign/SKILL.md

@@ -439,6 +439,8 @@ shasum -a 256 "${ACCOUNT_DIR}/e-sign/<DOC_REF>/base.pdf" | awk '{print $1}' \
 
 Before persisting, **read every rendered page** of `base.pdf` — full-bleed pages bleed correctly, no footer split across pages, no near-blank trailing page (§ 2 pagination; A4 dimensions are not proof of fit). If the deployed page is behind Cloudflare Access, do this base render in a session that can authenticate to Access — it is a one-time, operator-driven step, unlike dispatch (§ 6), which must never fetch the page at all. A new `DOC_REF` triggers a fresh render; an existing one keeps its persisted base.
 
+**The deployed signing-page URL is an explicit hand-back.** This deploy produces one value every downstream caller needs: the signing page's absolute `https://` URL — the canonical host (§ 7: `https://<project>.pages.dev`, or a custom domain mapped to it) joined to the document's slug (§ 1, e.g. `https://<project>.pages.dev/quote-lakeside-7f3a9c.html`). Return it to whatever flow invoked e-sign. **Invariant:** any external document that embeds a "Sign Online" / acceptance link — a quote, a proposal, a cover letter — must carry this exact value in that link, and **must not be finalised, exported, or sent before this deploy has produced it**. A Sign-Online link cannot point at a page that does not yet exist: deploy first, hand back the URL, then the caller injects it and renders. The quotation client-quote path is one such caller and gates on this — `sitedesk-job/skills/quotation/references/quote-generation.md` refuses to export a client quote whose Sign-Online anchor is not the live `https://` URL handed back here.
+
 ---
 
 ## 6. Sweep + dispatch

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

@@ -0,0 +1,25 @@
+# House-admin cross-account authority
+
+The house account is the operator-owned account that runs the admin assistant. Sub-accounts are isolated: each one's tools read and write only that account's data, which is what keeps tenants separate.
+
+By default the admin assistant is scoped the same way — it acts on the house account. Cross-account authority lets a house-scoped admin session act on a named sub-account by passing that account as a target, while every other session (public visitors, a session already scoped to a sub-account, background specialists) is refused. The refusal is fail-closed: a session that is not house-scoped and names a target is denied, never quietly redirected to its own account.
+
+The operator wants this for two surfaces: the account graph and the account filesystem. Each is a separate adoption; a coverage ledger tracks them and a background check confirms neither silently regresses.
+
+## Memory (graph)
+
+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.
+
+`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
+
+The `filesystem` plugin gives the admin session direct access to the account working directory (`data/accounts/<id>/`) — `SOUL.md`, generated documents, screenshots, arbitrary files. It exists because the native file tools (Read, Write, Edit, and the shell) are locked to the session's own account and cannot take a target. Its six tools are `file-read`, `file-write`, `file-edit`, `file-list`, `file-glob`, and `file-grep`.
+
+Omit the target and each tool acts on the session's own account, exactly like the native tools. Pass a sub-account as the target and a house-scoped admin session reads or writes that account's files instead; any other session that names a target is refused. Every path is confined to the resolved account directory — a path that climbs out with `../`, an absolute path outside the account root, or a symlink pointing away is rejected before anything is read or written, so the tools can never reach another account or the platform's own files.
+
+## Signals
+
+A standing background check reconciles live sessions against the account roles and raises an alarm if any session still holds house authority for an account that is no longer the house account, so a stale grant cannot sit unnoticed. Each cross-account tool call also records its decision — who called, which account it targeted, whether it was allowed, and why — before it touches the graph or disk, and a rejected filesystem path escape is recorded on its own line. In normal operation neither an allowed cross-account call from a non-house session nor a path escape ever appears.

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

@@ -156,6 +156,12 @@ If you want to write the public summary yourself — for instance, because the a
 
 People entries (`:Person`) are deliberately excluded from this dual-summary system. Notes about contacts are private by definition and never get a public-facing form.
 
+## 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 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.
+
 ## Privacy
 
 All memory is stored on your local Raspberry Pi. The Neo4j database never leaves your network. {{productName}} does not sync memory to any cloud service or third party.

package/payload/platform/plugins/filesystem/.claude-plugin/plugin.json

@@ -0,0 +1,21 @@
+{
+  "name": "filesystem",
+  "description": "Account-scoped file access. Read, write, edit, list, glob, and grep files under the session's own account directory; the house admin may reach any sub-account's files by naming targetAccountId, gated fail-closed and confined to that account's directory.",
+  "version": "0.1.0",
+  "author": {
+    "name": "Rubytech LLC"
+  },
+  "mcpServers": {
+    "filesystem": {
+      "type": "stdio",
+      "command": "node",
+      "args": [
+        "${CLAUDE_PLUGIN_ROOT}/lib/mcp-spawn-tee/index.js",
+        "${CLAUDE_PLUGIN_ROOT}/mcp/dist/index.js"
+      ],
+      "env": {
+        "MCP_SPAWN_TEE_NAME": "filesystem"
+      }
+    }
+  }
+}

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

@@ -0,0 +1,63 @@
+---
+name: filesystem
+description: "Account-scoped file access. Read, write, edit, list, glob, and grep files under the session's own account directory; the house admin may reach any sub-account's files by naming targetAccountId, gated fail-closed and confined to that account's directory."
+tools:
+  - name: file-read
+    publicAllowlist: false
+    adminAllowlist: true
+  - name: file-write
+    publicAllowlist: false
+    adminAllowlist: true
+  - name: file-edit
+    publicAllowlist: false
+    adminAllowlist: true
+  - name: file-list
+    publicAllowlist: false
+    adminAllowlist: true
+  - name: file-glob
+    publicAllowlist: false
+    adminAllowlist: true
+  - name: file-grep
+    publicAllowlist: false
+    adminAllowlist: true
+metadata: {"platform":{"always":false,"embed":[],"pluginKey":"filesystem"}}
+mcp:
+  command: node
+  args:
+    - ${PLATFORM_ROOT}/lib/mcp-spawn-tee/dist/index.js
+    - ${PLATFORM_ROOT}/plugins/filesystem/mcp/dist/index.js
+  env:
+    MCP_SPAWN_TEE_NAME: filesystem
+    LOG_DIR: ${LOG_DIR}
+    PLATFORM_ROOT: ${PLATFORM_ROOT}
+    ACCOUNT_ID: ${ACCOUNT_ID}
+    HOUSE_ADMIN_SCOPE: ${HOUSE_ADMIN_SCOPE}
+    SESSION_ID: ${SESSION_ID}
+    AGENT_SLUG: ${AGENT_SLUG}
+mcp-manifest: auto
+---
+
+# Filesystem
+
+Direct access to the account working directory (`data/accounts/<id>/`) — `SOUL.md`, generated documents, screenshots, and arbitrary files. These tools complement the native Read/Write/Edit tools, which are locked to your own account; only these tools can reach another account's files, and only for the house admin.
+
+## Own account
+
+Omit `targetAccountId`. Every tool takes a `path` relative to your account directory. `file-read`, `file-write`, `file-edit`, `file-list`, `file-glob`, and `file-grep` behave like their native counterparts but always resolve inside your account root.
+
+## Cross-account (house admin only)
+
+Pass `targetAccountId` to operate on a sub-account's directory. This is honoured only for a house-scoped admin session. A sub-account, specialist, or public session that passes `targetAccountId` is refused with `cross-account-denied`; an unknown account id is refused with `cross-account-invalid-target`. Use this to inspect or repair a client account's files from the house session without switching accounts.
+
+## Boundaries
+
+Every path is confined to the resolved account directory. A path that escapes it — `../`, an absolute path outside the account root, or a symlink pointing out — is rejected before any filesystem operation. Reads and greps skip files over 5 MB; grep skips binary files.
+
+## Tools
+
+- `file-read` — Read a UTF-8 file. Args: `path`, optional `targetAccountId`.
+- `file-write` — Create or overwrite a UTF-8 file, making parent directories. Args: `path`, `content`, optional `targetAccountId`.
+- `file-edit` — Replace one unique occurrence of `oldString` with `newString`. Fails if `oldString` is missing or not unique. Args: `path`, `oldString`, `newString`, optional `targetAccountId`.
+- `file-list` — List a directory's entries with their type. Args: optional `path` (defaults to the account root), optional `targetAccountId`.
+- `file-glob` — List files matching a glob (`**`, `*`, `?`). Args: `pattern`, optional `targetAccountId`.
+- `file-grep` — Search file contents for a JavaScript regular expression, returning `file:line:preview`. Args: `pattern`, optional `path`, optional `targetAccountId`.