@agent-native/core 0.149.2 → 0.149.3

package/dist/server/agents-bundle.js

@@ -20,7 +20,8 @@
  *
  * Result is cached in module scope so it's only computed once per cold start.
  */
-export const DEFAULT_SKILL_SCOPE = "both";
+import { DEFAULT_SKILL_SCOPE, isRuntimeVisibleScope, normalizeSkillScope, } from "./agent-chat/skill-frontmatter.js";
+export { DEFAULT_SKILL_SCOPE, isRuntimeVisibleScope, normalizeSkillScope, };
 const DEFAULT_AGENT_INSTRUCTIONS_PATH = "AGENTS.md";
 export function resolveAgentInstructionPaths(instructions) {
     return {
@@ -29,26 +30,6 @@ export function resolveAgentInstructionPaths(instructions) {
     };
 }
 let cached = null;
-/**
- * Coerce a raw frontmatter `scope` value into a known `SkillScope`. Unknown,
- * empty, or malformed values fall back to the default (`both`) so a typo never
- * silently hides a skill from the runtime agent. Optionally warns once per
- * distinct bad value to aid debugging without spamming logs.
- */
-const warnedBadScopes = new Set();
-export function normalizeSkillScope(raw) {
-    if (!raw)
-        return DEFAULT_SKILL_SCOPE;
-    const value = raw.trim().toLowerCase();
-    if (value === "runtime" || value === "dev" || value === "both") {
-        return value;
-    }
-    if (value && !warnedBadScopes.has(value)) {
-        warnedBadScopes.add(value);
-        console.warn(`[agents-bundle] Unknown skill scope "${raw}" — treating as "${DEFAULT_SKILL_SCOPE}". Valid values: runtime, dev, both.`);
-    }
-    return DEFAULT_SKILL_SCOPE;
-}
 /**
  * Parse the YAML frontmatter at the top of a skill file.
  * Only pulls out `name`, `description`, and `scope` — deliberately simple, no
@@ -57,8 +38,11 @@ export function normalizeSkillScope(raw) {
  *   - Inline: `description: Some text`
  *   - Folded scalar: `description: >-\n  multi\n  line` → "multi line"
  *   - Literal scalar: `description: |\n  multi\n  line` → "multi\nline"
+ *
+ * `sourceLabel` only names the file in the invalid-scope log; pass it wherever
+ * a path is known so a typo is traceable to the SKILL.md that carries it.
  */
-export function parseSkillFrontmatter(content) {
+export function parseSkillFrontmatter(content, sourceLabel) {
     const match = content.match(/^---\r?\n([\s\S]+?)\r?\n---/);
     if (!match)
         return {};
@@ -106,7 +90,7 @@ export function parseSkillFrontmatter(content) {
         else if (key === "description" && value)
             result.description = value;
         else if (key === "scope" && value)
-            result.scope = normalizeSkillScope(value);
+            result.scope = normalizeSkillScope(value, sourceLabel ?? result.name);
     }
     return result;
 }
@@ -170,7 +154,7 @@ function readSkillsDir(skillsDir, rootForRelative, out, skipExistingNames) {
             if (!fs.existsSync(realSkillFile))
                 continue;
             const content = fs.readFileSync(realSkillFile, "utf-8");
-            const meta = parseSkillFrontmatter(content);
+            const meta = parseSkillFrontmatter(content, path.relative(rootForRelative, skillFile).replace(/\\/g, "/"));
             const name = meta.name ?? entry.name;
             if (skipExistingNames && out[name])
                 continue; // Template wins
@@ -375,17 +359,19 @@ export async function loadAgentsBundle() {
  */
 /**
  * Skills visible to the agent-native RUNTIME agent. Excludes `scope: dev`
- * skills (those are for the human's coding agent only). Skills with no scope,
- * `scope: runtime`, or `scope: both` are all included. Use this anywhere the
- * runtime agent's view of skills is built (prompt block + docs-search) so a
- * dev-scoped skill is invisible to the runtime agent everywhere.
+ * skills (those are for the human's coding agent only) and skills whose scope
+ * could not be read. Skills with no scope, `scope: runtime`, or `scope: both`
+ * are all included. Use this anywhere the runtime agent's view of skills is
+ * built (prompt block + docs-search) so a dev-scoped skill is invisible to the
+ * runtime agent everywhere.
  */
 export function getRuntimeSkills(bundle) {
-    return Object.values(bundle.skills).filter((skill) => skill.meta.scope !== "dev");
+    return Object.values(bundle.skills).filter((skill) => isRuntimeVisibleScope(skill.meta.scope));
 }
 /**
  * Skills visible to development/coding agents. Excludes `scope: runtime`
- * skills that are intended only for the deployed in-app agent.
+ * skills that are intended only for the deployed in-app agent. An `invalid`
+ * scope stays visible here on purpose — this is the audience that can fix it.
  */
 export function getDevelopmentSkills(bundle) {
     return Object.values(bundle.skills).filter((skill) => skill.meta.scope !== "runtime");
@@ -437,14 +423,12 @@ function generateSkillsPromptBlockForEntries(entries, mode) {
                 extras = ` (also contains: ${s.extraFiles.join(", ")})`;
             }
         }
-        const runtimeHint = mode === "runtime"
-            ? ` Read with \`docs-search --slug "${skillDocsSlug(s.meta.name)}"\` before starting a task it applies to.`
-            : "";
+        const runtimeHint = mode === "runtime" ? ` [${skillDocsSlug(s.meta.name)}]` : "";
         return `- \`${s.meta.name}\` at \`${s.dir}/\` — ${s.meta.description || "(no description)"}${extras}${runtimeHint}`;
     });
     const readHint = mode === "runtime"
-        ? `To read a skill in the in-app runtime agent:
-  \`docs-search --slug "skill-<skill-name>"\`
+        ? `To read a skill in the in-app runtime agent, before starting a task it applies to:
+  \`docs-search --slug "<slug>"\` — each skill's slug is the [bracketed] token ending its line
   \`docs-search --query "<topic>"\` to discover matching docs/skills`
         : `To read a skill in dev mode (when you have bash access):
   \`bash(command="cat <skill-dir>/SKILL.md")\`

package/dist/server/better-auth-instance.d.ts

@@ -253,3 +253,4 @@ export declare function resetBetterAuth(): Promise<void>;
 export declare function configureLocalSqlite(sqlite: {
     pragma(statement: string): unknown;
 }): void;
+export declare function buildDatabaseConfig(dialect: string): Promise<BetterAuthOptions["database"]>;

package/dist/server/better-auth-instance.js

@@ -16,7 +16,7 @@ import { pgTable, text as pgText, timestamp as pgTimestamp, boolean as pgBoolean
 import { sqliteTable, text as sqliteText, integer as sqliteInteger, } from "drizzle-orm/sqlite-core";
 import { TEMPLATES } from "../cli/templates-meta.js";
 import { getDbExec, isPostgres } from "../db/client.js";
-import { getDialect, getDatabaseUrl, getDatabaseAuthToken, closePgliteClients, getPgliteClient, isPgliteUrl, loadPgliteDrizzle, pgPoolOptions, neonPoolOptions, guardNeonPool, sharedDbPool, onSharedDbPoolsClosed, onSharedDbPoolReplaced, } from "../db/client.js";
+import { getDialect, getCloudflareD1Binding, getDatabaseUrl, getDatabaseAuthToken, closePgliteClients, getPgliteClient, isPgliteUrl, loadPgliteDrizzle, pgPoolOptions, neonPoolOptions, guardNeonPool, sharedDbPool, onSharedDbPoolsClosed, onSharedDbPoolReplaced, } from "../db/client.js";
 import { CORE_RESET_PASSWORD_EMAIL_ID, CORE_VERIFY_SIGNUP_EMAIL_ID, } from "../email-catalog/system-emails.js";
 import { saveOAuthTokens } from "../oauth-tokens/store.js";
 import { acceptPendingInvitationsForEmail } from "../org/accept-pending.js";
@@ -1126,7 +1126,7 @@ export function configureLocalSqlite(sqlite) {
     sqlite.pragma("busy_timeout = 10000");
     sqlite.pragma("journal_mode = WAL");
 }
-async function buildDatabaseConfig(dialect) {
+export async function buildDatabaseConfig(dialect) {
     if (dialect === "postgres") {
         const url = getDatabaseUrl();
         const { buildResilientNeonPool, buildResilientPostgresJsClient, isNeonUrl, } = await import("../db/create-get-db.js");
@@ -1180,6 +1180,21 @@ async function buildDatabaseConfig(dialect) {
             schema: pgAuthSchema,
         });
     }
+    if (dialect === "d1") {
+        const d1 = getCloudflareD1Binding();
+        if (!d1) {
+            throw new Error("Cloudflare D1 database binding is unavailable; configure the DB binding before initializing Better Auth.");
+        }
+        const { drizzle } = await import("drizzle-orm/d1");
+        const db = drizzle(d1, {
+            schema: sqliteAuthSchema,
+        });
+        const { drizzleAdapter } = await import("better-auth/adapters/drizzle");
+        return drizzleAdapter(db, {
+            provider: "sqlite",
+            schema: sqliteAuthSchema,
+        });
+    }
     // SQLite / libsql
     const url = getDatabaseUrl("file:./data/app.db");
     if (url.startsWith("file:") || !url.includes("://")) {

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

@@ -2,7 +2,7 @@
  * Compact framework core instructions (FRAMEWORK_CORE_COMPACT).
  * Used in lazy-context mode (lazyContext: true — the default).
  *
- * Shares rules 8–9, 12–13 with the full variant via shared-rules.ts.
+ * Shares rules 8–9, 13–15 with the full variant via shared-rules.ts.
  * The compact version omits:
  *   - Verbose "Extended Capabilities" section (agent uses get-framework-context)
  *   - Detailed "Parallel Tool Calls" prose (replaced with one-liner)
@@ -18,6 +18,11 @@ export interface FrameworkCoreCompactPromptOptions {
      *  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>;
+    /** True for surfaces whose agent really can edit source (dev mode). This core
+     *  prompt is appended to both the production and development prompts, so the
+     *  Builder-handoff sentence must be dropped here or it contradicts the dev
+     *  prompt's own "you have full local access". */
+    canEditSource?: boolean;
 }
 /**
  * Build the compact FRAMEWORK_CORE prompt string.

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

@@ -2,7 +2,7 @@
  * Compact framework core instructions (FRAMEWORK_CORE_COMPACT).
  * Used in lazy-context mode (lazyContext: true — the default).
  *
- * Shares rules 8–9, 12–13 with the full variant via shared-rules.ts.
+ * Shares rules 8–9, 13–15 with the full variant via shared-rules.ts.
  * The compact version omits:
  *   - Verbose "Extended Capabilities" section (agent uses get-framework-context)
  *   - Detailed "Parallel Tool Calls" prose (replaced with one-liner)
@@ -10,7 +10,7 @@
  */
 import { frameworkGroupEnabled, } from "../../framework-tools.js";
 import { hasDatabaseReadTools, hasDatabaseWriteTools, } from "../../scripts/db/tool-mode.js";
-import { sharedRule8, SHARED_RULE_9, sharedRule14, SHARED_RULE_15, SHARED_RULE_AGENT_WARNINGS, } from "./shared-rules.js";
+import { sharedRule8, SHARED_RULE_9, sharedRule13, SHARED_RULE_14, SHARED_RULE_15, } from "./shared-rules.js";
 /**
  * Build the compact FRAMEWORK_CORE prompt string.
  *
@@ -54,10 +54,13 @@ For generated media, prefer this app's native generation action; otherwise use \
     const actionSurface = options?.extensionTools === true
         ? "registered actions, extensions, and MCP tools"
         : "registered actions and MCP tools";
+    const codeHandoffClause = options?.canEditSource === true
+        ? ""
+        : ", and hand code changes to Builder — you don't edit source yourself";
     return `
 ### How You Work
 
-Bring a senior engineer's judgment, arrived at through attention not premature certainty: understand the app's data and actions before acting, prefer existing actions and patterns over improvising, and keep work scoped. You act through ${actionSurface}, and hand code changes to Builder — you don't edit source yourself.
+Bring a senior engineer's judgment, arrived at through attention not premature certainty: understand the app's data and actions before acting, prefer existing actions and patterns over improvising, and keep work scoped. You act through ${actionSurface}${codeHandoffClause}.
 
 **Autonomy:** handle the task end to end this turn when feasible — take the actions, confirm they worked, report the outcome. Don't stop at a proposal or half-finished work; work through blockers yourself before handing back. In Plan mode, propose only.
 
@@ -76,18 +79,18 @@ Bring a senior engineer's judgment, arrived at through attention not premature c
 7. **Security** — ${securityRule}
 ${sharedRule8(examples, options)}
 ${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.
-${sharedRule14(options)}
+10. **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.
+11. **Downloadable files** — Deliver files in chat, never just a path.
+12. **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.
+${sharedRule13(options)}
+${SHARED_RULE_14}
 ${SHARED_RULE_15}
-${SHARED_RULE_AGENT_WARNINGS}
 
 ${resourcesSection}
 ### Extended Capabilities
 
 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\`.
+**Agent teams:** default to doing the work yourself; \`agent-teams\` can delegate to background sub-agents. 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. Read \`get-framework-context\` key \`agent-teams\` before spawning — it carries the fan-out limits, briefing contract, and why a spawn is not a completion.
 ${callAgentSection}`;
 }

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

@@ -2,7 +2,7 @@
  * Full framework core instructions (FRAMEWORK_CORE).
  * Used in the verbose prompt variant (lazyContext: false).
  *
- * Shared rules (8-9, 12-13) are imported from shared-rules.ts so the
+ * Shared rules (8-9, 13-15) 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";
@@ -15,6 +15,11 @@ export interface FrameworkCorePromptOptions {
      *  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>;
+    /** True for surfaces whose agent really can edit source (dev mode). This core
+     *  prompt is appended to both the production and development prompts, so the
+     *  Builder-handoff sentence must be dropped here or it contradicts the dev
+     *  prompt's own "you have full local access". */
+    canEditSource?: boolean;
 }
 /**
  * Build the full FRAMEWORK_CORE prompt string.

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

@@ -2,12 +2,12 @@
  * Full framework core instructions (FRAMEWORK_CORE).
  * Used in the verbose prompt variant (lazyContext: false).
  *
- * Shared rules (8-9, 12-13) are imported from shared-rules.ts so the
+ * Shared rules (8-9, 13-15) 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, sharedRule14, SHARED_RULE_15, SHARED_RULE_AGENT_WARNINGS, } from "./shared-rules.js";
+import { sharedRule8, SHARED_RULE_9, sharedRule13, SHARED_RULE_14, SHARED_RULE_15, } from "./shared-rules.js";
 /**
  * Build the full FRAMEWORK_CORE prompt string.
  *
@@ -41,6 +41,9 @@ 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 codeHandoffClause = options?.canEditSource === true
+        ? ""
+        : " — and you hand code changes to Builder rather than editing source yourself";
     const groupOn = (group) => frameworkGroupEnabled(options?.disabledFrameworkGroups, group);
     const resourcesSection = groupOn("resources")
         ? `### Resources
@@ -73,7 +76,7 @@ Workspace resources are user-facing by default. If you need temporary working fi
 
 You bring a senior engineer's judgment to this app, but you let it arrive through attention rather than premature certainty. Understand the app's data and actions before you act — read the current screen, the schema, and what tools exist — and let the shape of the existing system steer you. Prefer the app's own actions and established patterns over improvising a new approach. Keep your work scoped to what the request implies; don't redesign things that already work.
 
-You act through ${actionSurface} — and you hand code changes to Builder rather than editing source yourself. Within that surface, you own the task end to end.
+You act through ${actionSurface}${codeHandoffClause}. Within that surface, you own the task end to end.
 
 ### Autonomy And Persistence
 
@@ -102,13 +105,12 @@ ${refreshRule}
 ${securityRule}
 ${sharedRule8(examples, options)}
 ${SHARED_RULE_9}
-**Native chat widgets** — When an available action says it renders a native widget such as \`data-table\`, \`data-chart\`, or \`data-insights\`, call that action for user requests asking for a table, chart, graph, trend, report, or inline data view. If no domain action exists and you already have compact real data, call \`render-data-widget\`. Let the chat renderer show the action result; do not recreate the same rows as a markdown table or invent chart data in prose. Add only a short human summary or next-step link around the widget. Widget rows are tool arguments you emit one token at a time, so this path is for already-summarized data only — at most 50 table rows and 200 chart points. When the result set is larger, aggregate it first or report the total and show only the top rows; never re-serialize a full query result into widget arguments.
-**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.
-${sharedRule14(options)}
+10. **Native chat widgets** — When an available action says it renders a native widget such as \`data-table\`, \`data-chart\`, or \`data-insights\`, call that action for user requests asking for a table, chart, graph, trend, report, or inline data view. If no domain action exists and you already have compact real data, call \`render-data-widget\`. Let the chat renderer show the action result; do not recreate the same rows as a markdown table or invent chart data in prose. Add only a short human summary or next-step link around the widget. Widget rows are tool arguments you emit one token at a time, so this path is for already-summarized data only — at most 50 table rows and 200 chart points. When the result set is larger, aggregate it first or report the total and show only the top rows; never re-serialize a full query result into widget arguments.
+11. **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.
+12. **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.
+${sharedRule13(options)}
+${SHARED_RULE_14}
 ${SHARED_RULE_15}
-${SHARED_RULE_AGENT_WARNINGS}
 
 ### Parallel Tool Calls
 

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, sharedRule14, SHARED_RULE_15, type PromptExamples, type SharedRuleOptions, } from "./shared-rules.js";
+export { sharedRule8, SHARED_RULE_9, sharedRule13, SHARED_RULE_14, 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, sharedRule14, SHARED_RULE_15, } from "./shared-rules.js";
+export { sharedRule8, SHARED_RULE_9, sharedRule13, SHARED_RULE_14, SHARED_RULE_15, } from "./shared-rules.js";
 export { getModelFamilyOverlay } from "./model-overlays.js";

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

@@ -4,8 +4,13 @@
  * identical between them.
  *
  * Rules 8–9 (db-* tools; the consolidated no-fabrication / verify / recover
- * rule) and 12–13 (planning discipline; collaborate through uncertainty) are
- * reproduced verbatim in both prompts — keep them here.
+ * rule) and 13–15 (planning discipline; collaborate through uncertainty;
+ * relay agent warnings) are reproduced verbatim in both prompts — keep them
+ * here.
+ *
+ * Each identifier carries the number its text emits. Renumbering a rule means
+ * renaming its identifier in the same change; the two drifted apart once
+ * already and left people editing a different rule than the name said.
  */
 import { type FrameworkToolGroup } from "../../framework-tools.js";
 import { type DatabaseToolsOption } from "../../scripts/db/tool-mode.js";
@@ -30,7 +35,7 @@ export interface SharedRuleOptions {
 export declare function sharedRule8(examples?: PromptExamples, options?: SharedRuleOptions): string;
 /**
  * Rule 9 — Consolidated anti-fabrication rule (shared). Formerly three
- * separate rules (fabricating facts, fabricating success, and Rule 11's
+ * separate rules (fabricating facts, fabricating success, and a since-removed
  * "verify before you claim done") — merged because they are one behavior,
  * honesty about what actually happened, viewed from three angles. Keep all
  * three sub-behaviors distinct; do not re-split them back into separate
@@ -38,8 +43,8 @@ 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 (name retained as `sharedRule14` for import stability) — Planning and
- * progress. Deliberately states only when to open a progress run; the
+ * Rule 13 — 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
@@ -49,10 +54,11 @@ export declare const SHARED_RULE_9 = "9. **Never fabricate \u2014 verify results
  * 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 function sharedRule14(options?: SharedRuleOptions): string;
+export declare function sharedRule13(options?: SharedRuleOptions): string;
+/** Rule 14 — Collaborate through uncertainty (better-specified version). */
+export declare const SHARED_RULE_14 = "14. **Collaborate through uncertainty** \u2014 If a task stalls, errors, or depends on setup the user may not know about, shift into builder-coach mode instead of repeating the same attempt. State what you verified, name the most likely next checks, and proactively try common unblockers you can inspect (for example prompt size, missing environment variables, unavailable connections, current screen state, or tool choice). When you finish a meaningful step, offer one or two concrete next steps or improvements so non-technical users can keep iterating. When you are genuinely blocked on a decision you cannot resolve from context \u2014 and a wrong guess would be costly \u2014 use `ask-question` to present the choice instead of guessing; otherwise prefer a reasonable assumption and keep moving.";
 /**
- * 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.
+ * Rule 15 — Relay agent warnings.
  *
  * Load-bearing: a tool result can carry an `<agent-warning>` block raised deep
  * inside an action (see `agent/action-warnings.ts`) for an operation the caller
@@ -60,6 +66,4 @@ export declare function sharedRule14(options?: SharedRuleOptions): string;
  * Without this rule the model summarizes past the block and reports success,
  * which is the incident this channel was built to prevent.
  */
-export declare const SHARED_RULE_AGENT_WARNINGS = "14. **Relay `<agent-warning>` blocks before you report success** \u2014 A tool result may contain one or more `<agent-warning severity=\"...\" code=\"...\">` blocks. These are not part of the action's return value: they are raised by the operation the tool performed and they are the only place that consequence is reported. Never drop, bury, or paraphrase one away. On `severity=\"critical\"`, stop and tell the user what happened in your own words BEFORE any success summary \u2014 lead with the consequence and the remedy the block names, do not continue a multi-step plan whose later steps depend on the affected state, and if the operation is reversible say so and offer to reverse it. On `severity=\"advisory\"`, mention it in your final response. If a warning says something may already be broken, say that plainly; \"done\" is not an honest answer to a turn that raised a critical warning.";
-/** Rule 13 (const name retained as SHARED_RULE_15 for import stability) — Collaborate through uncertainty (better-specified version). */
-export declare const SHARED_RULE_15 = "13. **Collaborate through uncertainty** \u2014 If a task stalls, errors, or depends on setup the user may not know about, shift into builder-coach mode instead of repeating the same attempt. State what you verified, name the most likely next checks, and proactively try common unblockers you can inspect (for example prompt size, missing environment variables, unavailable connections, current screen state, or tool choice). When you finish a meaningful step, offer one or two concrete next steps or improvements so non-technical users can keep iterating. When you are genuinely blocked on a decision you cannot resolve from context \u2014 and a wrong guess would be costly \u2014 use `ask-question` to present the choice instead of guessing; otherwise prefer a reasonable assumption and keep moving.";
+export declare const SHARED_RULE_15 = "15. **Relay `<agent-warning>` blocks before you report success** \u2014 A tool result may contain one or more `<agent-warning severity=\"...\" code=\"...\">` blocks. These are not part of the action's return value: they are raised by the operation the tool performed and they are the only place that consequence is reported. Never drop, bury, or paraphrase one away. On `severity=\"critical\"`, stop and tell the user what happened in your own words BEFORE any success summary \u2014 lead with the consequence and the remedy the block names, do not continue a multi-step plan whose later steps depend on the affected state, and if the operation is reversible say so and offer to reverse it. On `severity=\"advisory\"`, mention it in your final response. If a warning says something may already be broken, say that plainly; \"done\" is not an honest answer to a turn that raised a critical warning.";

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

@@ -4,8 +4,13 @@
  * identical between them.
  *
  * Rules 8–9 (db-* tools; the consolidated no-fabrication / verify / recover
- * rule) and 12–13 (planning discipline; collaborate through uncertainty) are
- * reproduced verbatim in both prompts — keep them here.
+ * rule) and 13–15 (planning discipline; collaborate through uncertainty;
+ * relay agent warnings) are reproduced verbatim in both prompts — keep them
+ * here.
+ *
+ * Each identifier carries the number its text emits. Renumbering a rule means
+ * renaming its identifier in the same change; the two drifted apart once
+ * already and left people editing a different rule than the name said.
  */
 import { frameworkGroupEnabled, } from "../../framework-tools.js";
 import { normalizeDatabaseToolsMode, } from "../../scripts/db/tool-mode.js";
@@ -54,7 +59,7 @@ export function sharedRule8(examples, options) {
 }
 /**
  * Rule 9 — Consolidated anti-fabrication rule (shared). Formerly three
- * separate rules (fabricating facts, fabricating success, and Rule 11's
+ * separate rules (fabricating facts, fabricating success, and a since-removed
  * "verify before you claim done") — merged because they are one behavior,
  * honesty about what actually happened, viewed from three angles. Keep all
  * three sub-behaviors distinct; do not re-split them back into separate
@@ -65,8 +70,8 @@ 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 (name retained as `sharedRule14` for import stability) — Planning and
- * progress. Deliberately states only when to open a progress run; the
+ * Rule 13 — 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
@@ -76,15 +81,16 @@ export const SHARED_RULE_9 = `9. **Never fabricate — verify results, report fa
  * the rule never names a tool the request does not carry. The planning
  * discipline itself still applies — only the tool call goes away.
  */
-export function sharedRule14(options) {
+export function sharedRule13(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 `13. **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.`;
+    return `13. **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 — Collaborate through uncertainty (better-specified version). */
+export const SHARED_RULE_14 = `14. **Collaborate through uncertainty** — If a task stalls, errors, or depends on setup the user may not know about, shift into builder-coach mode instead of repeating the same attempt. State what you verified, name the most likely next checks, and proactively try common unblockers you can inspect (for example prompt size, missing environment variables, unavailable connections, current screen state, or tool choice). When you finish a meaningful step, offer one or two concrete next steps or improvements so non-technical users can keep iterating. When you are genuinely blocked on a decision you cannot resolve from context — and a wrong guess would be costly — use \`ask-question\` to present the choice instead of guessing; otherwise prefer a reasonable assumption and keep moving.`;
 /**
- * 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.
+ * Rule 15 — Relay agent warnings.
  *
  * Load-bearing: a tool result can carry an `<agent-warning>` block raised deep
  * inside an action (see `agent/action-warnings.ts`) for an operation the caller
@@ -92,6 +98,4 @@ export function sharedRule14(options) {
  * Without this rule the model summarizes past the block and reports success,
  * which is the incident this channel was built to prevent.
  */
-export const SHARED_RULE_AGENT_WARNINGS = `14. **Relay \`<agent-warning>\` blocks before you report success** — A tool result may contain one or more \`<agent-warning severity="..." code="...">\` blocks. These are not part of the action's return value: they are raised by the operation the tool performed and they are the only place that consequence is reported. Never drop, bury, or paraphrase one away. On \`severity="critical"\`, stop and tell the user what happened in your own words BEFORE any success summary — lead with the consequence and the remedy the block names, do not continue a multi-step plan whose later steps depend on the affected state, and if the operation is reversible say so and offer to reverse it. On \`severity="advisory"\`, mention it in your final response. If a warning says something may already be broken, say that plainly; "done" is not an honest answer to a turn that raised a critical warning.`;
-/** Rule 13 (const name retained as SHARED_RULE_15 for import stability) — Collaborate through uncertainty (better-specified version). */
-export const SHARED_RULE_15 = `13. **Collaborate through uncertainty** — If a task stalls, errors, or depends on setup the user may not know about, shift into builder-coach mode instead of repeating the same attempt. State what you verified, name the most likely next checks, and proactively try common unblockers you can inspect (for example prompt size, missing environment variables, unavailable connections, current screen state, or tool choice). When you finish a meaningful step, offer one or two concrete next steps or improvements so non-technical users can keep iterating. When you are genuinely blocked on a decision you cannot resolve from context — and a wrong guess would be costly — use \`ask-question\` to present the choice instead of guessing; otherwise prefer a reasonable assumption and keep moving.`;
+export const SHARED_RULE_15 = `15. **Relay \`<agent-warning>\` blocks before you report success** — A tool result may contain one or more \`<agent-warning severity="..." code="...">\` blocks. These are not part of the action's return value: they are raised by the operation the tool performed and they are the only place that consequence is reported. Never drop, bury, or paraphrase one away. On \`severity="critical"\`, stop and tell the user what happened in your own words BEFORE any success summary — lead with the consequence and the remedy the block names, do not continue a multi-step plan whose later steps depend on the affected state, and if the operation is reversible say so and offer to reverse it. On \`severity="advisory"\`, mention it in your final response. If a warning says something may already be broken, say that plainly; "done" is not an honest answer to a turn that raised a critical warning.`;

package/dist/server/realtime-token.d.ts

@@ -26,8 +26,8 @@ export declare function createRealtimeTokenHandler(): import("h3").EventHandlerW
     expiresAt?: undefined;
     ttlSeconds?: undefined;
 } | {
+    error?: undefined;
     token: string;
     expiresAt: string;
     ttlSeconds: number;
-    error?: undefined;
 }>>;

package/dist/server/transcribe-voice.d.ts

@@ -20,6 +20,6 @@ export declare function createTranscribeVoiceHandler(): import("h3").EventHandle
     error: string;
     text?: undefined;
 } | {
-    text: string;
     error?: undefined;
+    text: string;
 }>>;