@agent-native/core 0.144.3 → 0.145.1

package/dist/server/prompts/framework-core-compact.js

@@ -8,14 +8,37 @@
  *   - Detailed "Parallel Tool Calls" prose (replaced with one-liner)
  *   - Detailed "Resources" section (agent uses resources tool)
  */
+import { frameworkGroupEnabled, } from "../../framework-tools.js";
 import { hasDatabaseReadTools, hasDatabaseWriteTools, } from "../../scripts/db/tool-mode.js";
-import { sharedRule8, SHARED_RULE_9, SHARED_RULE_14, SHARED_RULE_15, SHARED_RULE_AGENT_WARNINGS, } from "./shared-rules.js";
+import { sharedRule8, SHARED_RULE_9, sharedRule14, SHARED_RULE_15, SHARED_RULE_AGENT_WARNINGS, } from "./shared-rules.js";
 /**
  * Build the compact FRAMEWORK_CORE prompt string.
  *
  * @param examples Optional injectable provider/action examples for rule 8.
  */
 export function buildFrameworkCoreCompact(examples, options) {
+    const groupOn = (group) => frameworkGroupEnabled(options?.disabledFrameworkGroups, group);
+    const resourcesSection = groupOn("resources")
+        ? `### Resources
+
+Use the \`resources\` tool for persistent notes and context files: \`action: "list"\`, \`"read"\`, \`"effective"\`, \`"write"\`, \`"promote"\`, or \`"delete"\`.
+Resources have three levels: workspace defaults inherited from Dispatch, shared organization/app overrides, and personal overrides. Use \`resources\` with \`action: "effective"\` before editing when you need to explain or inspect which level is active for a path.
+Workspace resources are user-facing by default. If you need temporary working files, write them as agent scratch (\`visibility: "agent_scratch"\`); scratch is hidden from the Workspace view by default and expires. Use \`visibility: "workspace"\` only when the user explicitly asked to save/manage that file, or for durable AGENTS.md, LEARNINGS.md, memory, skills, jobs, or custom agents.
+`
+        : "";
+    const extendedCapabilityClauses = [
+        "inline embeds",
+        groupOn("chat") ? "chat history search (`chat-history`)" : "",
+        groupOn("automation") ? "recurring jobs (`manage-jobs`)" : "",
+        "structured memory (`save-memory`/`delete-memory`)",
+        "browser automation (`activate-browser` in production, `set-browser-control` locally)",
+    ].filter(Boolean);
+    const extendedCapabilitiesList = `${extendedCapabilityClauses.slice(0, -1).join(", ")}, and ${extendedCapabilityClauses.at(-1)}`;
+    const callAgentSection = groupOn("workspaceApps")
+        ? `
+For generated media, prefer this app's native generation action; otherwise use \`call-agent\` with agent "assets".
+`
+        : "";
     const hasDatabaseTools = hasDatabaseReadTools(options?.databaseTools);
     const hasDatabaseWrites = hasDatabaseWriteTools(options?.databaseTools);
     const dataRule = hasDatabaseWrites
@@ -56,22 +79,15 @@ ${SHARED_RULE_9}
 **Native widgets** — For table/chart/graph/report requests, prefer actions labeled \`Native chat widget\`; use \`render-data-widget\` for already-summarized data (≤50 rows) instead of markdown tables. Above that, give the total plus the top rows — never retype a full result set as widget arguments. Deliver files in chat, never just a path.
 10. **Your tool list is not the whole surface** — Most app actions and connected MCP tools load on demand, so search the live registry with \`tool-search\` before concluding a capability doesn't exist.
 11. **Relative dates use runtime context** — The \`<runtime-context>\` block gives the authoritative current date/time. Resolve "today", "yesterday", "last week", and similar phrases to explicit calendar dates before querying data or creating artifacts.
-${SHARED_RULE_14}
+${sharedRule14(options)}
 ${SHARED_RULE_15}
 ${SHARED_RULE_AGENT_WARNINGS}
 
-### Resources
-
-Use the \`resources\` tool for persistent notes and context files: \`action: "list"\`, \`"read"\`, \`"effective"\`, \`"write"\`, \`"promote"\`, or \`"delete"\`.
-Resources have three levels: workspace defaults inherited from Dispatch, shared organization/app overrides, and personal overrides. Use \`resources\` with \`action: "effective"\` before editing when you need to explain or inspect which level is active for a path.
-Workspace resources are user-facing by default. If you need temporary working files, write them as agent scratch (\`visibility: "agent_scratch"\`); scratch is hidden from the Workspace view by default and expires. Use \`visibility: "workspace"\` only when the user explicitly asked to save/manage that file, or for durable AGENTS.md, LEARNINGS.md, memory, skills, jobs, or custom agents.
-
+${resourcesSection}
 ### Extended Capabilities
 
-You also have tools for inline embeds, chat history search (\`chat-history\`), recurring jobs (\`manage-jobs\`), structured memory (\`save-memory\`/\`delete-memory\`), and browser automation (\`activate-browser\` in production, \`set-browser-control\` locally). Call \`get-framework-context\` with the matching key — it lists its own topics — for full instructions when needed.
+You also have tools for ${extendedCapabilitiesList}. Call \`get-framework-context\` with the matching key — it lists its own topics — for full instructions when needed.
 
 **Agent teams:** default to doing the work yourself. Delegate ONE sub-agent (\`agent-teams\` action "spawn") for self-contained heavy work; fan out to several only for genuinely independent units; never parallelize tightly-coupled work; cap fan-out around 3. Treat "background agent", "sub-agent", "parallel", "batch", "kick off", "run the rest", and "queued items" as delegation intent when the user is asking you to start or continue independent work items. After \`spawn\`, say the task started/running, not completed; use \`status\`/\`read-result\` before claiming the delegated work is done. Give each sub-agent a self-contained brief (objective, the specific context/IDs it needs, output format, boundaries) — it can't see this thread — then read all results and synthesize one integrated answer. Full details: \`get-framework-context\` key \`agent-teams\`.
-
-For generated media, prefer this app's native generation action; otherwise use \`call-agent\` with agent "assets".
-`;
+${callAgentSection}`;
 }

package/dist/server/prompts/framework-core.d.ts

@@ -5,11 +5,16 @@
  * Shared rules (8-9, 12-13) are imported from shared-rules.ts so the
  * compact variant uses the same text and the two can never drift.
  */
+import { type FrameworkToolGroup } from "../../framework-tools.js";
 import { type DatabaseToolsOption } from "../../scripts/db/tool-mode.js";
 import { type PromptExamples } from "./shared-rules.js";
 export interface FrameworkCorePromptOptions {
     databaseTools?: DatabaseToolsOption;
     extensionTools?: boolean;
+    /** Framework tool groups this app switched off. Every block below that names
+     *  a group's tool by name is gated on this — a prompt naming an absent tool
+     *  makes the model call it, fail, and often report the capability as missing. */
+    disabledFrameworkGroups?: ReadonlySet<FrameworkToolGroup>;
 }
 /**
  * Build the full FRAMEWORK_CORE prompt string.

package/dist/server/prompts/framework-core.js

@@ -5,8 +5,9 @@
  * Shared rules (8-9, 12-13) are imported from shared-rules.ts so the
  * compact variant uses the same text and the two can never drift.
  */
+import { frameworkGroupEnabled, } from "../../framework-tools.js";
 import { hasDatabaseReadTools, hasDatabaseWriteTools, } from "../../scripts/db/tool-mode.js";
-import { sharedRule8, SHARED_RULE_9, SHARED_RULE_14, SHARED_RULE_15, SHARED_RULE_AGENT_WARNINGS, } from "./shared-rules.js";
+import { sharedRule8, SHARED_RULE_9, sharedRule14, SHARED_RULE_15, SHARED_RULE_AGENT_WARNINGS, } from "./shared-rules.js";
 /**
  * Build the full FRAMEWORK_CORE prompt string.
  *
@@ -40,6 +41,33 @@ export function buildFrameworkCore(examples, options) {
     const actionSurface = options?.extensionTools === true
         ? "this app's registered actions, extensions, and connected MCP tools"
         : "this app's registered actions and connected MCP tools";
+    const groupOn = (group) => frameworkGroupEnabled(options?.disabledFrameworkGroups, group);
+    const resourcesSection = groupOn("resources")
+        ? `### Resources
+
+You have access to a Resources system for persistent notes and context files.
+Use the \`resources\` tool to manage resources: \`action: "list"\`, \`"read"\`, \`"effective"\`, \`"write"\`, \`"promote"\`, or \`"delete"\`.
+Resources can be workspace defaults inherited from Dispatch, shared organization/app overrides, or personal overrides. By default, resources are personal. Workspace-scope resources are read-only from app agents; create shared or personal resources to override or narrow them.
+
+When the user gives instructions that should apply to all users/sessions, update the shared "AGENTS.md" resource.
+
+Workspace resources are user-facing by default. If you need temporary working files, use the \`resources\` tool with \`visibility: "agent_scratch"\`; scratch resources are hidden from the Workspace view by default and expire automatically. Use \`visibility: "workspace"\` only when the user explicitly asked to save/create/manage that file, or for durable control files such as \`AGENTS.md\`, \`LEARNINGS.md\`, \`memory/\`, \`skills/\`, \`jobs/\`, or \`agents/\`. If a scratch result becomes useful to the user, call \`resources\` with \`action: "promote"\` or rewrite it with \`visibility: "workspace"\`.
+`
+        : "";
+    const extendedCapabilityClauses = [
+        "inline embeds (`embed` fenced code block)",
+        groupOn("chat") ? "chat history search (`chat-history`)" : "",
+        groupOn("automation") ? "recurring jobs (`manage-jobs`)" : "",
+        "connecting Builder.io (`connect-builder`)",
+        "browser automation (`set-browser-control`/`activate-browser`)",
+        "structured memory (`save-memory`/`delete-memory`)",
+    ].filter(Boolean);
+    const extendedCapabilitiesList = `${extendedCapabilityClauses.slice(0, -1).join(", ")}, and ${extendedCapabilityClauses.at(-1)}`;
+    const callAgentSection = groupOn("workspaceApps")
+        ? `
+**call-agent** messages a DIFFERENT deployed app's agent over A2A — never use it for your own actions or to call yourself. For brand-consistent generated media when this app has no native generation action, call agent "assets".
+`
+        : "";
     return `
 ### How You Work
 
@@ -78,7 +106,7 @@ ${SHARED_RULE_9}
 **Downloadable files** — When the user asks you to create or export a file, deliver it in the same chat turn. For compact tabular results, prefer \`render-data-widget\` so the user gets the native Download CSV action without a second stored copy. For a complete or durable file written through \`workspaceWrite\`, use a normal non-\`scratch/\` path and then call \`show-workspace-file\` with that path so chat renders a direct download card. Never finish by giving filesystem paths or telling the user to navigate elsewhere to find the file.
 10. **Your tool list is not the whole surface** — Most app actions and connected MCP tools load on demand, so search the live registry with \`tool-search\` before concluding a capability doesn't exist.
 11. **Relative dates use runtime context** — The \`<runtime-context>\` block gives the authoritative current date/time. Resolve "today", "yesterday", "last week", and similar phrases to explicit calendar dates before querying data or creating artifacts. When answering factual questions, include the exact date or date range you used.
-${SHARED_RULE_14}
+${sharedRule14(options)}
 ${SHARED_RULE_15}
 ${SHARED_RULE_AGENT_WARNINGS}
 
@@ -86,22 +114,11 @@ ${SHARED_RULE_AGENT_WARNINGS}
 
 Gather context efficiently: when you need several independent read-only lookups (reading state, querying different tables, searching, fetching unrelated records), issue those tool calls together in one batch rather than one at a time. Keep mutating actions ordered and sequential — anything that creates, updates, deletes, sends, or publishes runs one at a time so each can be confirmed before the next, and so writes that depend on each other stay consistent.
 
-### Resources
-
-You have access to a Resources system for persistent notes and context files.
-Use the \`resources\` tool to manage resources: \`action: "list"\`, \`"read"\`, \`"effective"\`, \`"write"\`, \`"promote"\`, or \`"delete"\`.
-Resources can be workspace defaults inherited from Dispatch, shared organization/app overrides, or personal overrides. By default, resources are personal. Workspace-scope resources are read-only from app agents; create shared or personal resources to override or narrow them.
-
-When the user gives instructions that should apply to all users/sessions, update the shared "AGENTS.md" resource.
-
-Workspace resources are user-facing by default. If you need temporary working files, use the \`resources\` tool with \`visibility: "agent_scratch"\`; scratch resources are hidden from the Workspace view by default and expire automatically. Use \`visibility: "workspace"\` only when the user explicitly asked to save/create/manage that file, or for durable control files such as \`AGENTS.md\`, \`LEARNINGS.md\`, \`memory/\`, \`skills/\`, \`jobs/\`, or \`agents/\`. If a scratch result becomes useful to the user, call \`resources\` with \`action: "promote"\` or rewrite it with \`visibility: "workspace"\`.
-
+${resourcesSection}
 ### Extended Capabilities
 
-You also have tools for inline embeds (\`embed\` fenced code block), chat history search (\`chat-history\`), recurring jobs (\`manage-jobs\`), connecting Builder.io (\`connect-builder\`), browser automation (\`set-browser-control\`/\`activate-browser\`), and structured memory (\`save-memory\`/\`delete-memory\`). Call \`get-framework-context\` with the matching key — it lists its own topics — for full instructions before non-trivial work in any of these areas.
+You also have tools for ${extendedCapabilitiesList}. Call \`get-framework-context\` with the matching key — it lists its own topics — for full instructions before non-trivial work in any of these areas.
 
 **Agent teams:** default to doing the work yourself in this thread, but treat "background agent", "sub-agent", "parallel", "batch", "kick off", "run the rest", and "queued items" as delegation intent when the user is asking you to start or continue independent work items. Delegate ONE sub-agent for self-contained heavy work (deep research, long multi-step generation, noisy scans); fan out to MULTIPLE only for genuinely independent units; never parallelize tightly-coupled work; cap fan-out around 3. After \`spawn\`, say the task started/running, not completed; use \`status\`/\`read-result\` before claiming delegated work is done. Give every sub-agent a self-contained brief (objective, the specific context/IDs it needs, output format, boundaries), then read all results and synthesize one integrated answer. Full details: \`get-framework-context\` key \`agent-teams\`.
-
-**call-agent** messages a DIFFERENT deployed app's agent over A2A — never use it for your own actions or to call yourself. For brand-consistent generated media when this app has no native generation action, call agent "assets".
-`;
+${callAgentSection}`;
 }

package/dist/server/prompts/index.d.ts

@@ -4,5 +4,5 @@
  */
 export { buildFrameworkCore } from "./framework-core.js";
 export { buildFrameworkCoreCompact } from "./framework-core-compact.js";
-export { sharedRule8, SHARED_RULE_9, SHARED_RULE_14, SHARED_RULE_15, type PromptExamples, } from "./shared-rules.js";
+export { sharedRule8, SHARED_RULE_9, sharedRule14, SHARED_RULE_15, type PromptExamples, type SharedRuleOptions, } from "./shared-rules.js";
 export { getModelFamilyOverlay } from "./model-overlays.js";

package/dist/server/prompts/index.js

@@ -4,5 +4,5 @@
  */
 export { buildFrameworkCore } from "./framework-core.js";
 export { buildFrameworkCoreCompact } from "./framework-core-compact.js";
-export { sharedRule8, SHARED_RULE_9, SHARED_RULE_14, SHARED_RULE_15, } from "./shared-rules.js";
+export { sharedRule8, SHARED_RULE_9, sharedRule14, SHARED_RULE_15, } from "./shared-rules.js";
 export { getModelFamilyOverlay } from "./model-overlays.js";

package/dist/server/prompts/shared-rules.d.ts

@@ -7,6 +7,7 @@
  * rule) and 12–13 (planning discipline; collaborate through uncertainty) are
  * reproduced verbatim in both prompts — keep them here.
  */
+import { type FrameworkToolGroup } from "../../framework-tools.js";
 import { type DatabaseToolsOption } from "../../scripts/db/tool-mode.js";
 /**
  * Injectable provider/action examples. Defaults are generic; templates that
@@ -21,6 +22,9 @@ export interface PromptExamples {
 export interface SharedRuleOptions {
     databaseTools?: DatabaseToolsOption;
     extensionTools?: boolean;
+    /** Framework tool groups this app switched off. Any rule naming a group's
+     *  tool must drop that reference — see `frameworkGroupEnabled`. */
+    disabledFrameworkGroups?: ReadonlySet<FrameworkToolGroup>;
 }
 /** Rule 8 — db-* tools are internal only (shared between full and compact). */
 export declare function sharedRule8(examples?: PromptExamples, options?: SharedRuleOptions): string;
@@ -34,14 +38,18 @@ export declare function sharedRule8(examples?: PromptExamples, options?: SharedR
  */
 export declare const SHARED_RULE_9 = "9. **Never fabricate \u2014 verify results, report failures honestly, and recover instead of giving up.**\n   - **Never fabricate factual claims or records** \u2014 do not invent numbers, metrics, records, query results, URLs, citations, source attributions, customer names, dates, or success rates. This applies inside generated artifacts too: decks, documents, reports, dashboards, Slack/email replies, and charts. Only state factual numbers/claims the user provided or you retrieved with an action/tool. If a data source is unavailable, returns no rows, is missing credentials, or has a connection error, say so clearly; do not create placeholder rows or fetch unrelated providers to look complete unless the user explicitly asked you to import/sync/backfill. Prefer qualitative wording, placeholders like `[metric TBD]`, or clearly labeled draft assumptions over plausible-looking facts \u2014 presenting made-up data as real is worse than admitting the limitation.\n   - **Never fabricate success from tool errors** \u2014 when a tool call returns an error (marked `isError: true`, contains \"Command failed\", \"Error:\", or non-zero exit output), the operation FAILED; do not synthesize a success narrative or describe what it \"would have\" produced. Report the failure verbatim (this applies especially to `bash(command=\"pnpm action ...\")` calls). Before telling the user a mutating action (create/update/delete/send/publish) is done, confirm it actually landed \u2014 check the tool result, or read the refreshed `<current-screen>` / re-query the data; having *called* an action is not proof it worked. If a result is ambiguous, check rather than assume.\n   - **Recover instead of giving up** \u2014 treat a failure or ambiguous result as a signal to retry the obvious fix, try an alternate tool or approach, or clearly hand the blocker back with what you tried; never silently give up, and never paper over a failure by claiming success.";
 /**
- * Rule 12 (const name retained as SHARED_RULE_14 for import stability) —
- * Planning and progress. Deliberately states only when to open a progress run;
- * the start/update/complete discipline lives in `manage-progress`'s own tool
+ * Rule 12 (name retained as `sharedRule14` for import stability) — Planning and
+ * progress. Deliberately states only when to open a progress run; the
+ * start/update/complete discipline lives in `manage-progress`'s own tool
  * description (packages/core/src/progress/actions.ts). Re-adding the mechanics
  * here means every turn pays for guidance the model only needs once it has the
  * tool loaded.
+ *
+ * Drops the `manage-progress` reference when the `automation` group is off, so
+ * the rule never names a tool the request does not carry. The planning
+ * discipline itself still applies — only the tool call goes away.
  */
-export declare const SHARED_RULE_14 = "12. **Plan and track multi-step work** \u2014 When a task spans several real steps the user would want to watch, open a `manage-progress` run so the work is visible while it's still in flight, and keep it updated as you go rather than after the fact; the tool's own description carries the full discipline. Skip it for single-action lookups, simple reads, and anything that finishes in one tool call \u2014 never create single-step plans.";
+export declare function sharedRule14(options?: SharedRuleOptions): string;
 /**
  * Rule 14 — Relay agent warnings. Named for what it is rather than its number,
  * since the `SHARED_RULE_14`/`15` names above no longer match theirs.

package/dist/server/prompts/shared-rules.js

@@ -7,6 +7,7 @@
  * rule) and 12–13 (planning discipline; collaborate through uncertainty) are
  * reproduced verbatim in both prompts — keep them here.
  */
+import { frameworkGroupEnabled, } from "../../framework-tools.js";
 import { normalizeDatabaseToolsMode, } from "../../scripts/db/tool-mode.js";
 const DEFAULT_PROVIDER_ACTIONS = [
     "provider-search",
@@ -64,14 +65,23 @@ export const SHARED_RULE_9 = `9. **Never fabricate — verify results, report fa
    - **Never fabricate success from tool errors** — when a tool call returns an error (marked \`isError: true\`, contains "Command failed", "Error:", or non-zero exit output), the operation FAILED; do not synthesize a success narrative or describe what it "would have" produced. Report the failure verbatim (this applies especially to \`bash(command="pnpm action ...")\` calls). Before telling the user a mutating action (create/update/delete/send/publish) is done, confirm it actually landed — check the tool result, or read the refreshed \`<current-screen>\` / re-query the data; having *called* an action is not proof it worked. If a result is ambiguous, check rather than assume.
    - **Recover instead of giving up** — treat a failure or ambiguous result as a signal to retry the obvious fix, try an alternate tool or approach, or clearly hand the blocker back with what you tried; never silently give up, and never paper over a failure by claiming success.`;
 /**
- * Rule 12 (const name retained as SHARED_RULE_14 for import stability) —
- * Planning and progress. Deliberately states only when to open a progress run;
- * the start/update/complete discipline lives in `manage-progress`'s own tool
+ * Rule 12 (name retained as `sharedRule14` for import stability) — Planning and
+ * progress. Deliberately states only when to open a progress run; the
+ * start/update/complete discipline lives in `manage-progress`'s own tool
  * description (packages/core/src/progress/actions.ts). Re-adding the mechanics
  * here means every turn pays for guidance the model only needs once it has the
  * tool loaded.
+ *
+ * Drops the `manage-progress` reference when the `automation` group is off, so
+ * the rule never names a tool the request does not carry. The planning
+ * discipline itself still applies — only the tool call goes away.
  */
-export const SHARED_RULE_14 = `12. **Plan and track multi-step work** — When a task spans several real steps the user would want to watch, open a \`manage-progress\` run so the work is visible while it's still in flight, and keep it updated as you go rather than after the fact; the tool's own description carries the full discipline. Skip it for single-action lookups, simple reads, and anything that finishes in one tool call — never create single-step plans.`;
+export function sharedRule14(options) {
+    if (!frameworkGroupEnabled(options?.disabledFrameworkGroups, "automation")) {
+        return `12. **Plan and track multi-step work** — When a task spans several real steps, work through them in order and tell the user where you are as you go rather than only at the end. Skip ceremony for single-action lookups, simple reads, and anything that finishes in one tool call.`;
+    }
+    return `12. **Plan and track multi-step work** — When a task spans several real steps the user would want to watch, open a \`manage-progress\` run so the work is visible while it's still in flight, and keep it updated as you go rather than after the fact; the tool's own description carries the full discipline. Skip it for single-action lookups, simple reads, and anything that finishes in one tool call — never create single-step plans.`;
+}
 /**
  * Rule 14 — Relay agent warnings. Named for what it is rather than its number,
  * since the `SHARED_RULE_14`/`15` names above no longer match theirs.

package/dist/server/session-email-cache.d.ts

@@ -0,0 +1,14 @@
+export declare function getCachedSessionEmail(token: string): string | undefined;
+export declare function setCachedSessionEmail(token: string, email: string): void;
+export declare function forgetCachedSessionEmail(token: string): void;
+/**
+ * Drop cached session resolutions. Call after ANY write to `sessions`.
+ *
+ * Clears every token rather than one: the bulk sign-out paths delete by email
+ * (`DELETE FROM sessions WHERE email = ?`) and do not know which tokens they
+ * removed, so a per-token eviction there would leave a signed-out session
+ * resolving for the rest of the TTL.
+ */
+export declare function invalidateSessionEmailCache(): void;
+/** Test seam — the cache is module state, so suites must be able to clear it. */
+export declare function __resetSessionEmailCacheForTests(): void;

package/dist/server/session-email-cache.js

@@ -0,0 +1,48 @@
+import { createTtlCache } from "../shared/ttl-cache.js";
+/**
+ * Cross-request cache for resolved legacy session tokens.
+ *
+ * A session token is immutable for its (30-day) lifetime, yet every
+ * authenticated request re-read it: production showed 494,848 of these for 3
+ * users, 1:1 with the request count. The TTL is far shorter than the session
+ * lifetime, so expiry is enforced at most `SESSION_EMAIL_TTL_MS` late — a 30-day
+ * boundary observed up to 15s late changes nothing.
+ *
+ * ONLY successful resolutions belong in here. A `null` — no such token, expired,
+ * revoked — must stay uncached so a sign-out or a token that has just been
+ * written is never answered from a stale negative, and so an auth failure can
+ * never be made sticky by a cache.
+ *
+ * Lives in its own module rather than in `auth.ts` because `auth.ts` imports
+ * `org/auth-policy.ts`, which also revokes sessions and so needs to invalidate
+ * this. Importing back into `auth.ts` from there would be a cycle.
+ */
+const SESSION_EMAIL_TTL_MS = 15_000;
+const sessionEmailCache = createTtlCache({
+    ttlMs: SESSION_EMAIL_TTL_MS,
+    maxEntries: 4_096,
+});
+export function getCachedSessionEmail(token) {
+    return sessionEmailCache.get(token);
+}
+export function setCachedSessionEmail(token, email) {
+    sessionEmailCache.set(token, email);
+}
+export function forgetCachedSessionEmail(token) {
+    sessionEmailCache.delete(token);
+}
+/**
+ * Drop cached session resolutions. Call after ANY write to `sessions`.
+ *
+ * Clears every token rather than one: the bulk sign-out paths delete by email
+ * (`DELETE FROM sessions WHERE email = ?`) and do not know which tokens they
+ * removed, so a per-token eviction there would leave a signed-out session
+ * resolving for the rest of the TTL.
+ */
+export function invalidateSessionEmailCache() {
+    sessionEmailCache.clear();
+}
+/** Test seam — the cache is module state, so suites must be able to clear it. */
+export function __resetSessionEmailCacheForTests() {
+    sessionEmailCache.clear();
+}

package/dist/server/sweep-runtime.d.ts

@@ -0,0 +1,22 @@
+type SweepRuntimeEnvKey = "AGENT_NATIVE_DISABLE_INPROCESS_SWEEPS";
+type SweepRuntimeEnv = Partial<Record<SweepRuntimeEnvKey, string | undefined>>;
+/**
+ * Kill switch for the `setInterval` backstop sweeps.
+ *
+ * These timers are correct on a long-lived Node server: one process, one timer
+ * set, one query per tick. On a serverless host they are billed per WARM
+ * CONTAINER, not per deployment — every warm instance independently runs the
+ * whole timer set, so the sweep query rate scales with instance count, which no
+ * in-process backoff or `lastSweep` guard can observe. A production sample
+ * showed one 2-minute sweep issuing 237k queries, implying ~11 containers each
+ * ticking forever against a database that then never gets to autosuspend.
+ *
+ * Default OFF (sweeps run), because on every host where the timers are the only
+ * thing driving recovery, disabling them silently strands queued work. Turn this
+ * on ONLY where a durable platform scheduler already drives the same recovery —
+ * the shape `isNetlifyRecurringJobsRuntime` + the emitted scheduled sweep
+ * already implement for recurring jobs, and which these three sweeps should
+ * eventually adopt instead of needing this switch at all.
+ */
+export declare function shouldDisableInProcessSweeps(env?: SweepRuntimeEnv): boolean;
+export {};

package/dist/server/sweep-runtime.js

@@ -0,0 +1,28 @@
+// ---------------------------------------------------------------------------
+// Gating for the in-process backstop sweep timers (automation redispatch,
+// agent-teams orphan reconciliation, durable sandbox executions).
+// ---------------------------------------------------------------------------
+function isTruthyEnv(value) {
+    return /^(1|true|yes|on)$/i.test(value?.trim() ?? "");
+}
+/**
+ * Kill switch for the `setInterval` backstop sweeps.
+ *
+ * These timers are correct on a long-lived Node server: one process, one timer
+ * set, one query per tick. On a serverless host they are billed per WARM
+ * CONTAINER, not per deployment — every warm instance independently runs the
+ * whole timer set, so the sweep query rate scales with instance count, which no
+ * in-process backoff or `lastSweep` guard can observe. A production sample
+ * showed one 2-minute sweep issuing 237k queries, implying ~11 containers each
+ * ticking forever against a database that then never gets to autosuspend.
+ *
+ * Default OFF (sweeps run), because on every host where the timers are the only
+ * thing driving recovery, disabling them silently strands queued work. Turn this
+ * on ONLY where a durable platform scheduler already drives the same recovery —
+ * the shape `isNetlifyRecurringJobsRuntime` + the emitted scheduled sweep
+ * already implement for recurring jobs, and which these three sweeps should
+ * eventually adopt instead of needing this switch at all.
+ */
+export function shouldDisableInProcessSweeps(env = process.env) {
+    return isTruthyEnv(env.AGENT_NATIVE_DISABLE_INPROCESS_SWEEPS);
+}

package/dist/settings/store.js

@@ -25,6 +25,24 @@ function requestSettingsCache() {
     }
     return cache;
 }
+/**
+ * Per-request memo of the WHOLE settings table for `getAllSettings`.
+ *
+ * The single-key path above was already request-cached; the full-table read was
+ * not, and production showed 98,479 of them — an entire `SELECT key, value FROM
+ * settings` per call, several times per request via the MCP client routes and
+ * org settings.
+ *
+ * Holds raw JSON strings, like the single-key cache, so callers can't mutate a
+ * shared parsed object. Dropped by every write path, because a request that
+ * writes a setting and then re-reads all of them must see its own write.
+ */
+const _requestAllSettingsCache = new WeakMap();
+function invalidateRequestAllSettings() {
+    const ctx = getRequestContext();
+    if (ctx && typeof ctx === "object")
+        _requestAllSettingsCache.delete(ctx);
+}
 // Created lazily so this module can be evaluated in the browser dev graph
 // without a top-level `new EventEmitter()` tripping Vite's externalized
 // `node:events` stub. The emitter drives server-side SSE fan-out only.
@@ -152,6 +170,7 @@ export async function mutateSetting(key, updater, options) {
         if (result.rowsAffected === 0)
             continue;
         requestSettingsCache()?.set(key, nextRaw);
+        invalidateRequestAllSettings();
         settingsEmitter().emit("settings", {
             source: "settings",
             type: "change",
@@ -173,6 +192,7 @@ export async function putSetting(key, value, options) {
         args: [key, JSON.stringify(value), Date.now()],
     });
     requestSettingsCache()?.set(key, JSON.stringify(value));
+    invalidateRequestAllSettings();
     settingsEmitter().emit("settings", {
         source: "settings",
         type: "change",
@@ -189,6 +209,7 @@ export async function deleteSetting(key, options) {
         args: [key],
     });
     requestSettingsCache()?.set(key, null);
+    invalidateRequestAllSettings();
     if (result.rowsAffected > 0) {
         settingsEmitter().emit("settings", {
             source: "settings",
@@ -215,6 +236,7 @@ export async function deleteSettingsByPrefix(prefix, options) {
         args: [`${escaped}%`],
     });
     requestSettingsCache()?.clear();
+    invalidateRequestAllSettings();
     if (result.rowsAffected > 0) {
         settingsEmitter().emit("settings", {
             source: "settings",
@@ -226,13 +248,47 @@ export async function deleteSettingsByPrefix(prefix, options) {
     return result.rowsAffected;
 }
 export async function getAllSettings() {
-    await ensureTable();
-    const client = getDbExec();
-    const table = settingsTable();
-    const { rows } = await client.execute(`SELECT key, value FROM ${table}`);
+    const raw = await loadAllSettingsRaw();
     const result = {};
-    for (const row of rows) {
-        result[row.key] = JSON.parse(row.value);
-    }
+    for (const [key, value] of raw)
+        result[key] = JSON.parse(value);
     return result;
 }
+async function loadAllSettingsRaw() {
+    const ctx = getRequestContext();
+    const cached = ctx && typeof ctx === "object"
+        ? _requestAllSettingsCache.get(ctx)
+        : undefined;
+    if (cached)
+        return cached;
+    const load = (async () => {
+        await ensureTable();
+        const client = getDbExec();
+        const table = settingsTable();
+        const { rows } = await client.execute(`SELECT key, value FROM ${table}`);
+        const raw = new Map();
+        for (const row of rows)
+            raw.set(row.key, row.value);
+        // Seed the single-key cache so a `getSetting` after `getAllSettings` in the
+        // same request is free rather than another round trip. Only fills keys it
+        // does not already hold: a value written earlier in this request is already
+        // written through there and must win over this snapshot.
+        const perKey = requestSettingsCache();
+        if (perKey) {
+            for (const [key, value] of raw) {
+                if (!perKey.has(key))
+                    perKey.set(key, value);
+            }
+        }
+        return raw;
+    })();
+    if (ctx && typeof ctx === "object") {
+        // Evicted on failure so one transient error is not memoized as the answer
+        // for the rest of the request.
+        _requestAllSettingsCache.set(ctx, load.catch((err) => {
+            _requestAllSettingsCache.delete(ctx);
+            throw err;
+        }));
+    }
+    return load;
+}

package/dist/shared/ttl-cache.d.ts

@@ -0,0 +1,59 @@
+/**
+ * Bounded process-level TTL cache for answers that are expensive to re-fetch
+ * and safe to serve slightly stale.
+ *
+ * ## Which cache do I want?
+ *
+ * This repo has exactly two general caching patterns. Reach for an existing one
+ * rather than hand-rolling a third `Map` with timestamps in it:
+ *
+ * 1. **Request-scoped** — `WeakMap<RequestContext, Map<...>>`, freed with the
+ *    request. Use when repeated reads within ONE request must collapse but no
+ *    answer may outlive it. See `settings/store.ts` (`requestSettingsCache`),
+ *    `org/request-org-cache.ts`, `secrets/storage.ts`.
+ * 2. **Process-scoped with a TTL** — this module. Use when every request
+ *    re-reads the same value and staleness bounded by the TTL is acceptable.
+ *    Every consumer must also wire an invalidation path for the writes that
+ *    change the answer; the TTL is a backstop, not the correctness story.
+ *
+ * Two caches deliberately do NOT use this and should stay as they are, because
+ * flattening them into this shape would lose behavior they depend on:
+ *
+ * - `server/poll.ts`'s collab access cache — different TTL per outcome
+ *   (allow vs deny), a per-resource invalidation epoch, and in-flight request
+ *   dedup.
+ * - `demo/redact.ts` — a bidirectional memo (forward map plus a produced-value
+ *   reverse index) with refresh-on-read recency, needed for round-trip
+ *   stability.
+ *
+ * The per-request memos elsewhere in this codebase (`event.context` caches,
+ * `requestSettingsCache`) collapse repeated reads WITHIN one request. They do
+ * nothing for a value every request re-reads identically — a session token's
+ * email, an account's org memberships — which on a remote Postgres is a round
+ * trip per request per value, forever.
+ *
+ * ## Only cache successful reads
+ *
+ * Never `set` a value that stands for "I could not read this". A cached
+ * "unreadable" is indistinguishable from a cached "absent" to every later
+ * caller, which is exactly how a transient blip turns into a
+ * permanent-looking wrong answer. Leave failures on the uncached path so they
+ * stay loud and retryable.
+ *
+ * ## Bounded on purpose
+ *
+ * Keys here are user-supplied (session tokens, emails), so an unbounded map is
+ * a memory leak that grows with traffic. `maxEntries` evicts oldest-written
+ * first once the cap is reached.
+ */
+export interface TtlCache<V> {
+    get(key: string): V | undefined;
+    set(key: string, value: V): void;
+    delete(key: string): void;
+    clear(): void;
+    readonly size: number;
+}
+export declare function createTtlCache<V>(options: {
+    ttlMs: number;
+    maxEntries: number;
+}): TtlCache<V>;

package/dist/shared/ttl-cache.js

@@ -0,0 +1,43 @@
+export function createTtlCache(options) {
+    const { ttlMs, maxEntries } = options;
+    if (!(ttlMs > 0)) {
+        throw new Error(`createTtlCache: ttlMs must be positive, got ${ttlMs}`);
+    }
+    if (!(maxEntries > 0)) {
+        throw new Error(`createTtlCache: maxEntries must be positive, got ${maxEntries}`);
+    }
+    const entries = new Map();
+    return {
+        get(key) {
+            const hit = entries.get(key);
+            if (!hit)
+                return undefined;
+            if (hit.expiresAt <= Date.now()) {
+                entries.delete(key);
+                return undefined;
+            }
+            return hit.value;
+        },
+        set(key, value) {
+            // Delete before insert so Map insertion order tracks the newest write,
+            // which is what the eviction loop below reads as "oldest".
+            entries.delete(key);
+            entries.set(key, { value, expiresAt: Date.now() + ttlMs });
+            while (entries.size > maxEntries) {
+                const oldest = entries.keys().next();
+                if (oldest.done)
+                    break;
+                entries.delete(oldest.value);
+            }
+        },
+        delete(key) {
+            entries.delete(key);
+        },
+        clear() {
+            entries.clear();
+        },
+        get size() {
+            return entries.size;
+        },
+    };
+}

package/dist/sharing/actions/list-resource-shares.d.ts

@@ -12,9 +12,9 @@ declare const _default: import("../../action.js").ActionDefinition<{
     orgId?: undefined;
     role?: undefined;
 } | {
-    ownerEmail: any;
-    orgId: any;
-    visibility: any;
+    ownerEmail: string;
+    orgId: string;
+    visibility: import("../schema.js").Visibility;
     role: "owner" | import("../schema.js").ShareRole;
     shares: any;
     policy: {

package/dist/sharing/actions/list-resource-shares.js

@@ -43,7 +43,10 @@ export default defineAction({
             allowPublic: reg.allowPublic !== false,
             requireOrgMemberForUserShares: reg.requireOrgMemberForUserShares === true,
         };
-        const access = await resolveAccess(args.resourceType, args.resourceId);
+        // Only `ownerEmail`/`orgId`/`visibility` are read below, all of which the
+        // projected load carries — so the share dialog never pulls a resource's
+        // body blob just to render who it is shared with.
+        const access = await resolveAccess(args.resourceType, args.resourceId, undefined, { skipResourceBody: true });
         if (!access)
             return { ownerEmail: null, visibility: null, shares: [], policy };
         const db = reg.getDb();