@restforgejs/mcp-server 1.2.1 → 1.2.2

package/dist/server.js

@@ -5,6 +5,7 @@ import { registerHealthTools } from './tools/health/index.js';
 import { registerSetupTools } from './tools/setup/index.js';
 import { registerCodegenTools } from './tools/codegen/index.js';
 import { registerRuntimeTools } from './tools/runtime/index.js';
+import { registerDesignerTools } from './tools/designer/index.js';
 const SERVER_NAME = 'restforge-mcp';
 // Read the version from package.json at runtime so the advertised server version
 // never drifts from the published package version. createRequire resolves the JSON
@@ -227,6 +228,49 @@ documentationUrl returned by each catalog points to narrative
 documentation which may lag behind the most recent npm release; trust
 the catalog data over the URL for property reference, but use the URL
 for use case examples and decision guides.
+
+DESIGNER (FRONTEND) DOMAIN:
+The codegen/setup/runtime tools above all wrap the backend CLI
+('restforge', the @restforgejs/platform package). A separate family of
+tools — the 'designer_*' tools — wraps a DIFFERENT command-line product,
+'restforge-designer' (the RESTForge Designer frontend generator). Keep
+the two straight: backend payload/schema/API work goes through the
+'restforge' tools; frontend application work goes through the
+'designer_*' tools.
+
+Prefer the 'designer_*' tools when the user wants to:
+- Generate, validate, or preview a FRONTEND application (not a backend
+  API) from a UI Definition File (UDF) payload
+- Work with a frontend/designer PLUGIN (list, inspect, scaffold) — plugin
+  ids look like 'vanilla-js-basic', 'vanilla-js-auth', 'vanilla-js-custom'
+- Initialise a new frontend project from a designer plugin
+- Phrases like "generate frontend", "build the UI from this payload",
+  "generate aplikasi frontend", "preview file frontend", "buat project
+  frontend dari plugin", "validate UDF", or any mention of
+  "restforge-designer", "designer", "rfd", or "frontend generation"
+
+Detection signals that this is RESTForge Designer (frontend) work:
+- The 'restforge-designer' binary (alias 'rfd') is installed and on PATH
+- The user mentions UDF (UI Definition File), frontend generation, or a
+  designer plugin ('vanilla-js-*')
+- A frontend project folder with a UDF payload (payload/NN-<name>.json
+  in the frontend project) is in play
+
+Boundaries for the designer domain:
+- The 'designer_*' tools wrap the 'restforge-designer' binary, which is a
+  product SEPARATE from the backend 'restforge' CLI. They are not
+  interchangeable; do not route a backend RDF/SDF request to a
+  'designer_*' tool, or a UDF/frontend request to a 'codegen_*' tool.
+- Designer LICENSE management and activation/deactivation are NOT
+  available through this MCP server (consistent with the backend, which
+  also does not manage per-machine license here). When a license-gated
+  designer operation (init, generate) fails because the license is not
+  active, relay that and tell the user to activate their RESTForge
+  Designer license through the Designer desktop application or its own
+  CLI — this server cannot activate it.
+- If the 'restforge-designer' binary is not installed or not on PATH, the
+  designer tools return a non-error precondition; relay it as a setup
+  step (install RESTForge Designer), not a failure.
 `.trim();
 export async function startServer() {
     const server = new McpServer({
@@ -239,6 +283,7 @@ export async function startServer() {
     registerSetupTools(server);
     registerCodegenTools(server);
     registerRuntimeTools(server);
+    registerDesignerTools(server);
     const transport = new StdioServerTransport();
     await server.connect(transport);
 }

package/dist/server.js.map

@@ -1 +1 @@
-{"version":3,"file":"server.js","sourceRoot":"","sources":["../src/server.ts"],"names":[],"mappings":"AAAA,OAAO,EAAE,aAAa,EAAE,MAAM,aAAa,CAAC;AAC5C,OAAO,EAAE,SAAS,EAAE,MAAM,yCAAyC,CAAC;AACpE,OAAO,EAAE,oBAAoB,EAAE,MAAM,2CAA2C,CAAC;AACjF,OAAO,EAAE,mBAAmB,EAAE,MAAM,yBAAyB,CAAC;AAC9D,OAAO,EAAE,kBAAkB,EAAE,MAAM,wBAAwB,CAAC;AAC5D,OAAO,EAAE,oBAAoB,EAAE,MAAM,0BAA0B,CAAC;AAChE,OAAO,EAAE,oBAAoB,EAAE,MAAM,0BAA0B,CAAC;AAEhE,MAAM,WAAW,GAAG,eAAe,CAAC;AAEpC,iFAAiF;AACjF,mFAAmF;AACnF,6EAA6E;AAC7E,mFAAmF;AACnF,gFAAgF;AAChF,kFAAkF;AAClF,MAAM,OAAO,GAAG,aAAa,CAAC,MAAM,CAAC,IAAI,CAAC,GAAG,CAAC,CAAC;AAC/C,MAAM,EAAE,OAAO,EAAE,cAAc,EAAE,GAAG,OAAO,CAAC,iBAAiB,CAAwB,CAAC;AAEtF,MAAM,mBAAmB,GAAG;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CAqN3B,CAAC,IAAI,EAAE,CAAC;AAET,MAAM,CAAC,KAAK,UAAU,WAAW;IAC/B,MAAM,MAAM,GAAG,IAAI,SAAS,CAC1B;QACE,IAAI,EAAE,WAAW;QACjB,OAAO,EAAE,cAAc;KACxB,EACD;QACE,YAAY,EAAE,mBAAmB;KAClC,CACF,CAAC;IAEF,mBAAmB,CAAC,MAAM,EAAE,cAAc,CAAC,CAAC;IAC5C,kBAAkB,CAAC,MAAM,CAAC,CAAC;IAC3B,oBAAoB,CAAC,MAAM,CAAC,CAAC;IAC7B,oBAAoB,CAAC,MAAM,CAAC,CAAC;IAE7B,MAAM,SAAS,GAAG,IAAI,oBAAoB,EAAE,CAAC;IAC7C,MAAM,MAAM,CAAC,OAAO,CAAC,SAAS,CAAC,CAAC;AAClC,CAAC"}
+{"version":3,"file":"server.js","sourceRoot":"","sources":["../src/server.ts"],"names":[],"mappings":"AAAA,OAAO,EAAE,aAAa,EAAE,MAAM,aAAa,CAAC;AAC5C,OAAO,EAAE,SAAS,EAAE,MAAM,yCAAyC,CAAC;AACpE,OAAO,EAAE,oBAAoB,EAAE,MAAM,2CAA2C,CAAC;AACjF,OAAO,EAAE,mBAAmB,EAAE,MAAM,yBAAyB,CAAC;AAC9D,OAAO,EAAE,kBAAkB,EAAE,MAAM,wBAAwB,CAAC;AAC5D,OAAO,EAAE,oBAAoB,EAAE,MAAM,0BAA0B,CAAC;AAChE,OAAO,EAAE,oBAAoB,EAAE,MAAM,0BAA0B,CAAC;AAChE,OAAO,EAAE,qBAAqB,EAAE,MAAM,2BAA2B,CAAC;AAElE,MAAM,WAAW,GAAG,eAAe,CAAC;AAEpC,iFAAiF;AACjF,mFAAmF;AACnF,6EAA6E;AAC7E,mFAAmF;AACnF,gFAAgF;AAChF,kFAAkF;AAClF,MAAM,OAAO,GAAG,aAAa,CAAC,MAAM,CAAC,IAAI,CAAC,GAAG,CAAC,CAAC;AAC/C,MAAM,EAAE,OAAO,EAAE,cAAc,EAAE,GAAG,OAAO,CAAC,iBAAiB,CAAwB,CAAC;AAEtF,MAAM,mBAAmB,GAAG;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CAgQ3B,CAAC,IAAI,EAAE,CAAC;AAET,MAAM,CAAC,KAAK,UAAU,WAAW;IAC/B,MAAM,MAAM,GAAG,IAAI,SAAS,CAC1B;QACE,IAAI,EAAE,WAAW;QACjB,OAAO,EAAE,cAAc;KACxB,EACD;QACE,YAAY,EAAE,mBAAmB;KAClC,CACF,CAAC;IAEF,mBAAmB,CAAC,MAAM,EAAE,cAAc,CAAC,CAAC;IAC5C,kBAAkB,CAAC,MAAM,CAAC,CAAC;IAC3B,oBAAoB,CAAC,MAAM,CAAC,CAAC;IAC7B,oBAAoB,CAAC,MAAM,CAAC,CAAC;IAC7B,qBAAqB,CAAC,MAAM,CAAC,CAAC;IAE9B,MAAM,SAAS,GAAG,IAAI,oBAAoB,EAAE,CAAC;IAC7C,MAAM,MAAM,CAAC,OAAO,CAAC,SAAS,CAAC,CAAC;AAClC,CAAC"}

package/dist/tools/codegen/dbschema-apply.js

@@ -37,56 +37,56 @@ function extractWarningsAndSummary(stdout) {
 export function registerCodegenDbschemaApply(server) {
     server.registerTool('codegen_dbschema_apply', {
         title: 'Apply Schema Drift Incrementally via ALTER',
-        description: `Resolve schema drift from dbschema-kit SDF files to the live database via incremental ALTER TABLE statements, by wrapping restforge schema apply. This is the incremental complement of 'codegen_dbschema_diff' (which only detects drift) and the SAFE alternative to 'codegen_dbschema_migrate' with drop=true (which destroys and recreates tables). By default the apply is ADDITIVE-ONLY: ADD COLUMN, CREATE INDEX, ADD UNIQUE, and ADD FOREIGN KEY are emitted; every destructive change is skipped with a warning unless explicitly opted in (allowDrop for DROP COLUMN/INDEX/UNIQUE/FOREIGN KEY, allowModify for ALTER COLUMN length/nullable and FOREIGN KEY action changes).
-
-RECOMMENDED WORKFLOW:
-1. Run 'codegen_dbschema_diff' first to see the drift.
-2. Run this tool with dryRun=true to preview the exact ALTER statements.
-3. Show the preview to the user and ask for confirmation.
-4. Only then run with dryRun=false to apply. Pass allowDrop/allowModify ONLY when the user explicitly asked for that destructive change — never to "make a warning go away".
-
-EXIT CODE SEMANTICS (important):
-- Exit 0 = success: every applicable drift was applied (or previewed in dry-run, or there was no drift). The output may still contain warnings for operations the platform defers (see below) — relay those.
-- Exit 1 = some drift was SKIPPED because it requires allowDrop or allowModify. This is a NORMAL, meaningful result — NOT a failure. In a real apply the additive statements WERE applied; only the skipped items remain. NEVER retry automatically with allowDrop/allowModify: those options drop or mutate data and need explicit user confirmation first.
-- Exit 2 = system error (invalid config, SDF load failure, connection failure, or apply failure). ROLLBACK means the database is unchanged; PARTIAL means some statements were applied and the database needs manual inspection.
-
-USE WHEN:
-- 'codegen_dbschema_diff' reported drift and the user wants to bring the database in sync incrementally
-- The user asks "apply the drift", "sinkronkan database dengan schema", "tambahkan kolom yang kurang ke database", "apply perubahan schema tanpa drop"
-- Evolving an existing populated database without recreating tables (data preserved)
-- The user wants a preview of the ALTER statements first — pass dryRun=true (safe path)
-
-DO NOT USE FOR:
-- Detecting drift without changing anything -> use 'codegen_dbschema_diff' (read-only)
-- Full CREATE/DROP deployment of a schema or initial setup of an empty database -> use 'codegen_dbschema_migrate'
-- Retrofitting the soft-delete consistency CHECK -> not supported here (detection-only); goes through 'codegen_dbschema_migrate' with drop (destructive) or manual SQL
-- Type changes, PK changes, default value changes, CHECK constraint changes -> not supported by the platform yet (always skipped); suggest a manual SQL migration
-- Validating SDF file correctness -> use 'codegen_dbschema_validate'
-- Reverse-engineering SDF files from the database -> use 'codegen_dbschema_introspect'
-
-This tool runs: npx restforge schema apply --path=<path> --config=<config> [--table=<name>] [--dry-run] [--allow-drop] [--allow-modify] in the given cwd. The output is a structured human-readable report (DDL preview or per-statement progress, Warnings, Summary) — there is no JSON mode.
-
-OPERATIONS NOT SUPPORTED by the platform yet (always skipped with a 'deferred' warning, regardless of opt-in flags):
-- ALTER COLUMN type change (needs a data conversion strategy per dialect)
-- ALTER COLUMN precision/scale change
-- DEFAULT value change
-- PRIMARY KEY changes (need a table rebuild)
-- CHECK constraint add/drop
-On SQLite, MODIFY/DROP COLUMN and ALL foreign key changes are additionally skipped ('sqlite limitation') even with opt-in flags; the sqlite dialect is rejected entirely by the default introspector.
-
-Soft-delete note: drift in the soft-delete consistency CHECK is detection-only. It is reported as a warning (never auto-applied) and does NOT by itself cause exit 1; the warning text suggests retrofitting via 'schema migrate --drop' (recreate) or adding the CHECK manually.
-
-Preconditions:
-- The project must have @restforgejs/platform installed in node_modules.
-- The config file (default 'db-connection.env') must exist and contain valid database credentials.
-- SDF files must exist at the given path. The --path flag is required by the CLI.
-
-PRESENTATION GUIDANCE:
-- Match the user's language. If the user writes in Indonesian, respond in Indonesian.
-- Never mention internal tool names in the reply to the user. Describe actions by what they do (e.g. "apply the missing columns", "preview the ALTER statements").
-- Exit 1 is NOT an error. Present it as: "these changes were applied/previewed, these were skipped because they would drop or modify existing data". Then ask the user whether they want the destructive part — do not decide for them.
-- This tool MUTATES the live database when dryRun=false. Prefer dryRun=true on the first call and confirm with the user before the real apply.
-- Speak in plain language. Summarise the applied/skipped items; do not paste raw CLI output unless the user explicitly asks.
+        description: `Resolve schema drift from dbschema-kit SDF files to the live database via incremental ALTER TABLE statements, by wrapping restforge schema apply. This is the incremental complement of 'codegen_dbschema_diff' (which only detects drift) and the SAFE alternative to 'codegen_dbschema_migrate' with drop=true (which destroys and recreates tables). By default the apply is ADDITIVE-ONLY: ADD COLUMN, CREATE INDEX, ADD UNIQUE, and ADD FOREIGN KEY are emitted; every destructive change is skipped with a warning unless explicitly opted in (allowDrop for DROP COLUMN/INDEX/UNIQUE/FOREIGN KEY, allowModify for ALTER COLUMN length/nullable and FOREIGN KEY action changes).
+
+RECOMMENDED WORKFLOW:
+1. Run 'codegen_dbschema_diff' first to see the drift.
+2. Run this tool with dryRun=true to preview the exact ALTER statements.
+3. Show the preview to the user and ask for confirmation.
+4. Only then run with dryRun=false to apply. Pass allowDrop/allowModify ONLY when the user explicitly asked for that destructive change — never to "make a warning go away".
+
+EXIT CODE SEMANTICS (important):
+- Exit 0 = success: every applicable drift was applied (or previewed in dry-run, or there was no drift). The output may still contain warnings for operations the platform defers (see below) — relay those.
+- Exit 1 = some drift was SKIPPED because it requires allowDrop or allowModify. This is a NORMAL, meaningful result — NOT a failure. In a real apply the additive statements WERE applied; only the skipped items remain. NEVER retry automatically with allowDrop/allowModify: those options drop or mutate data and need explicit user confirmation first.
+- Exit 2 = system error (invalid config, SDF load failure, connection failure, or apply failure). ROLLBACK means the database is unchanged; PARTIAL means some statements were applied and the database needs manual inspection.
+
+USE WHEN:
+- 'codegen_dbschema_diff' reported drift and the user wants to bring the database in sync incrementally
+- The user asks "apply the drift", "sinkronkan database dengan schema", "tambahkan kolom yang kurang ke database", "apply perubahan schema tanpa drop"
+- Evolving an existing populated database without recreating tables (data preserved)
+- The user wants a preview of the ALTER statements first — pass dryRun=true (safe path)
+
+DO NOT USE FOR:
+- Detecting drift without changing anything -> use 'codegen_dbschema_diff' (read-only)
+- Full CREATE/DROP deployment of a schema or initial setup of an empty database -> use 'codegen_dbschema_migrate'
+- Retrofitting the soft-delete consistency CHECK -> not supported here (detection-only); goes through 'codegen_dbschema_migrate' with drop (destructive) or manual SQL
+- Type changes, PK changes, default value changes, CHECK constraint changes -> not supported by the platform yet (always skipped); suggest a manual SQL migration
+- Validating SDF file correctness -> use 'codegen_dbschema_validate'
+- Reverse-engineering SDF files from the database -> use 'codegen_dbschema_introspect'
+
+This tool runs: npx restforge schema apply --path=<path> --config=<config> [--table=<name>] [--dry-run] [--allow-drop] [--allow-modify] in the given cwd. The output is a structured human-readable report (DDL preview or per-statement progress, Warnings, Summary) — there is no JSON mode.
+
+OPERATIONS NOT SUPPORTED by the platform yet (always skipped with a 'deferred' warning, regardless of opt-in flags):
+- ALTER COLUMN type change (needs a data conversion strategy per dialect)
+- ALTER COLUMN precision/scale change
+- DEFAULT value change
+- PRIMARY KEY changes (need a table rebuild)
+- CHECK constraint add/drop
+On SQLite, MODIFY/DROP COLUMN and ALL foreign key changes are additionally skipped ('sqlite limitation') even with opt-in flags; the sqlite dialect is rejected entirely by the default introspector.
+
+Soft-delete note: drift in the soft-delete consistency CHECK is detection-only. It is reported as a warning (never auto-applied) and does NOT by itself cause exit 1; the warning text suggests retrofitting via 'schema migrate --drop' (recreate) or adding the CHECK manually.
+
+Preconditions:
+- The project must have @restforgejs/platform installed in node_modules.
+- The config file (default 'db-connection.env') must exist and contain valid database credentials.
+- SDF files must exist at the given path. The --path flag is required by the CLI.
+
+PRESENTATION GUIDANCE:
+- Match the user's language. If the user writes in Indonesian, respond in Indonesian.
+- Never mention internal tool names in the reply to the user. Describe actions by what they do (e.g. "apply the missing columns", "preview the ALTER statements").
+- Exit 1 is NOT an error. Present it as: "these changes were applied/previewed, these were skipped because they would drop or modify existing data". Then ask the user whether they want the destructive part — do not decide for them.
+- This tool MUTATES the live database when dryRun=false. Prefer dryRun=true on the first call and confirm with the user before the real apply.
+- Speak in plain language. Summarise the applied/skipped items; do not paste raw CLI output unless the user explicitly asks.
 - When a precondition is not met, frame it as a question or next-step suggestion rather than an error.`,
         inputSchema: {
             cwd: z
@@ -136,18 +136,18 @@ PRESENTATION GUIDANCE:
                 content: [
                     {
                         type: 'text',
-                        text: `Precondition not met: the RESTForge package is not installed in this project.
-
-Project path: ${projectCwd}
-Expected location: node_modules/@restforgejs/platform
-Requested config: ${config}
-Requested schema path: ${path}
-Requested table filter: ${table ?? 'all tables'}
-Requested dryRun: ${dryRun}
-
-For the assistant:
-- The user needs to install the RESTForge package before drift can be applied to the database.
-- Suggest installing the package first, then retry the apply.
+                        text: `Precondition not met: the RESTForge package is not installed in this project.
+
+Project path: ${projectCwd}
+Expected location: node_modules/@restforgejs/platform
+Requested config: ${config}
+Requested schema path: ${path}
+Requested table filter: ${table ?? 'all tables'}
+Requested dryRun: ${dryRun}
+
+For the assistant:
+- The user needs to install the RESTForge package before drift can be applied to the database.
+- Suggest installing the package first, then retry the apply.
 - When explaining to the user, say something like "the RESTForge package isn't installed yet — should I install it first?". Do not mention internal tool names.`,
                     },
                 ],
@@ -188,38 +188,38 @@ For the assistant:
                 content: [
                     {
                         type: 'text',
-                        text: `Failed to apply schema drift to the database.
-
-Project path: ${projectCwd}
-Config: ${config}
-Schema path: ${path}
-Table filter: ${table ?? 'all tables'}
-Mode: ${dryRun ? 'dry-run' : 'apply'}
-Command: ${result.command}
-Exit code: ${result.exitCode}
-
---- CLI output ---
-stdout:
-${result.stdout}
-
-stderr:
-${result.stderr}
---- end CLI output ---
-
-For the assistant:
-- Tell the user that the apply could not complete. This is a system error, not a drift result.
-- Check the CLI output for ROLLBACK or PARTIAL status first:
-  * ROLLBACK applied — the database state is UNCHANGED; the failed statement is reported. Safe to fix the cause and retry.
-  * Partial apply detected — SOME statements were applied before the failure and were NOT reverted. The user must inspect the database state manually before any retry.
-- Other common causes, in plain language:
-  * Config file not found or invalid — suggest verifying the config path and its content.
-  * Database connection failed — suggest verifying credentials, host, and port.
-  * Schema path not found or no models in it — suggest verifying the folder or file name passed via --path.
-  * SDF load error — a schema file has invalid syntax or violates the defineModel contract. Suggest running the validate action first.
-  * Table filter not found in SDF — the --table value does not match any model.
-  * Unsupported dialect — schema apply does not support sqlite. Suggest checking DB_TYPE in the config.
-  * Unknown command 'schema apply' — the installed RESTForge version may be older than this CLI subcommand; suggest upgrading the package.
-- Do not paste the raw stdout/stderr unless the user explicitly asks. Do not mention internal tool names.
+                        text: `Failed to apply schema drift to the database.
+
+Project path: ${projectCwd}
+Config: ${config}
+Schema path: ${path}
+Table filter: ${table ?? 'all tables'}
+Mode: ${dryRun ? 'dry-run' : 'apply'}
+Command: ${result.command}
+Exit code: ${result.exitCode}
+
+--- CLI output ---
+stdout:
+${result.stdout}
+
+stderr:
+${result.stderr}
+--- end CLI output ---
+
+For the assistant:
+- Tell the user that the apply could not complete. This is a system error, not a drift result.
+- Check the CLI output for ROLLBACK or PARTIAL status first:
+  * ROLLBACK applied — the database state is UNCHANGED; the failed statement is reported. Safe to fix the cause and retry.
+  * Partial apply detected — SOME statements were applied before the failure and were NOT reverted. The user must inspect the database state manually before any retry.
+- Other common causes, in plain language:
+  * Config file not found or invalid — suggest verifying the config path and its content.
+  * Database connection failed — suggest verifying credentials, host, and port.
+  * Schema path not found or no models in it — suggest verifying the folder or file name passed via --path.
+  * SDF load error — a schema file has invalid syntax or violates the defineModel contract. Suggest running the validate action first.
+  * Table filter not found in SDF — the --table value does not match any model.
+  * Unsupported dialect — schema apply does not support sqlite. Suggest checking DB_TYPE in the config.
+  * Unknown command 'schema apply' — the installed RESTForge version may be older than this CLI subcommand; suggest upgrading the package.
+- Do not paste the raw stdout/stderr unless the user explicitly asks. Do not mention internal tool names.
 - Offer to retry once the underlying issue is resolved (after manual inspection in the PARTIAL case).`,
                     },
                 ],
@@ -234,28 +234,28 @@ For the assistant:
                 content: [
                     {
                         type: 'text',
-                        text: `Schema apply ${dryRun ? 'dry-run ' : ''}completed with skipped drift: some changes require explicit opt-in (this is a result, not an error).
-
-Project path: ${projectCwd}
-Config: ${config}
-Schema path: ${path}
-Table filter: ${table ?? 'all tables'}
-Mode: ${dryRun ? 'dry-run (nothing applied)' : 'apply (additive statements WERE applied)'}
-
---- Warnings and Summary (from the CLI) ---
-${excerpt}
---- end Warnings and Summary ---
-
---- Full CLI output ---
-${result.stdout}
---- end Full CLI output ---
-
-For the assistant:
-- Present this as a two-part factual result: (1) what was ${dryRun ? 'previewed' : 'applied'} — see the ${dryRun ? 'DDL preview' : 'progress lines'} in the full output; (2) what was SKIPPED — the Warnings above list each skipped item with its reason ('requires --allow-drop' or 'requires --allow-modify').
-- ${dryRun ? 'This was a preview only. Nothing was applied to the database.' : 'The additive statements were applied to the live database; only the skipped items remain outstanding.'}
-- Do NOT retry with allowDrop/allowModify on your own. Those options drop columns/constraints or alter existing columns — explain to the user what would be dropped or modified, and only proceed after the user explicitly confirms.
-- Warnings with reason 'deferred', 'detection-only', or 'sqlite limitation' cannot be resolved by opt-in flags at all — those need a manual migration or a full recreate; say so plainly.
-- Do not paste the full CLI output unless the user asks; the Warnings/Summary excerpt is usually enough.
+                        text: `Schema apply ${dryRun ? 'dry-run ' : ''}completed with skipped drift: some changes require explicit opt-in (this is a result, not an error).
+
+Project path: ${projectCwd}
+Config: ${config}
+Schema path: ${path}
+Table filter: ${table ?? 'all tables'}
+Mode: ${dryRun ? 'dry-run (nothing applied)' : 'apply (additive statements WERE applied)'}
+
+--- Warnings and Summary (from the CLI) ---
+${excerpt}
+--- end Warnings and Summary ---
+
+--- Full CLI output ---
+${result.stdout}
+--- end Full CLI output ---
+
+For the assistant:
+- Present this as a two-part factual result: (1) what was ${dryRun ? 'previewed' : 'applied'} — see the ${dryRun ? 'DDL preview' : 'progress lines'} in the full output; (2) what was SKIPPED — the Warnings above list each skipped item with its reason ('requires --allow-drop' or 'requires --allow-modify').
+- ${dryRun ? 'This was a preview only. Nothing was applied to the database.' : 'The additive statements were applied to the live database; only the skipped items remain outstanding.'}
+- Do NOT retry with allowDrop/allowModify on your own. Those options drop columns/constraints or alter existing columns — explain to the user what would be dropped or modified, and only proceed after the user explicitly confirms.
+- Warnings with reason 'deferred', 'detection-only', or 'sqlite limitation' cannot be resolved by opt-in flags at all — those need a manual migration or a full recreate; say so plainly.
+- Do not paste the full CLI output unless the user asks; the Warnings/Summary excerpt is usually enough.
 - Match the user's language.`,
                     },
                 ],
@@ -268,23 +268,23 @@ For the assistant:
                 content: [
                     {
                         type: 'text',
-                        text: `Schema apply dry-run completed (no changes applied).
-
-Project path: ${projectCwd}
-Config: ${config}
-Schema path: ${path}
-Table filter: ${table ?? 'all tables'}
-Mode: dry-run
-
---- DDL preview ---
-${result.stdout}
---- end DDL preview ---
-
-For the assistant:
-- Confirm to the user that this was a preview only. No ALTER statement was applied to the database.
-- The statements shown above are exactly what would run if the same action is repeated without dry-run. "No applicable ALTER statements." means schema and database are already in sync for the applicable operations.
-- If a Warnings block is present, relay it: warnings with reason 'deferred', 'detection-only', or 'sqlite limitation' are operations the platform cannot apply incrementally yet (they do not block the rest).
-- Encourage the user to review the preview, then confirm before running the real apply.
+                        text: `Schema apply dry-run completed (no changes applied).
+
+Project path: ${projectCwd}
+Config: ${config}
+Schema path: ${path}
+Table filter: ${table ?? 'all tables'}
+Mode: dry-run
+
+--- DDL preview ---
+${result.stdout}
+--- end DDL preview ---
+
+For the assistant:
+- Confirm to the user that this was a preview only. No ALTER statement was applied to the database.
+- The statements shown above are exactly what would run if the same action is repeated without dry-run. "No applicable ALTER statements." means schema and database are already in sync for the applicable operations.
+- If a Warnings block is present, relay it: warnings with reason 'deferred', 'detection-only', or 'sqlite limitation' are operations the platform cannot apply incrementally yet (they do not block the rest).
+- Encourage the user to review the preview, then confirm before running the real apply.
 - Match the user's language.`,
                     },
                 ],
@@ -295,26 +295,26 @@ For the assistant:
             content: [
                 {
                     type: 'text',
-                    text: `Schema apply completed successfully: all applicable drift was applied.
-
-Project path: ${projectCwd}
-Config: ${config}
-Schema path: ${path}
-Table filter: ${table ?? 'all tables'}
-Mode: apply
-allowDrop: ${allowDrop}
-allowModify: ${allowModify}
-
---- CLI output ---
-${result.stdout}
---- end CLI output ---
-
-For the assistant:
-- Confirm to the user that the incremental changes were applied to the live database. "No drift to apply." means schema and database were already in sync.
-- Read the Summary in the CLI output and mention the number of statements applied in plain language.
-- If skipped warnings are present (reason 'deferred', 'detection-only', or 'sqlite limitation'), relay them: those operations cannot be applied incrementally yet and need a manual migration or a full recreate. They did not block this apply.
-- Suggest verifying the result with a drift check (read-only) if the user wants confirmation that everything is now in sync.
-- Do not paste the raw CLI output unless the user explicitly asks.
+                    text: `Schema apply completed successfully: all applicable drift was applied.
+
+Project path: ${projectCwd}
+Config: ${config}
+Schema path: ${path}
+Table filter: ${table ?? 'all tables'}
+Mode: apply
+allowDrop: ${allowDrop}
+allowModify: ${allowModify}
+
+--- CLI output ---
+${result.stdout}
+--- end CLI output ---
+
+For the assistant:
+- Confirm to the user that the incremental changes were applied to the live database. "No drift to apply." means schema and database were already in sync.
+- Read the Summary in the CLI output and mention the number of statements applied in plain language.
+- If skipped warnings are present (reason 'deferred', 'detection-only', or 'sqlite limitation'), relay them: those operations cannot be applied incrementally yet and need a manual migration or a full recreate. They did not block this apply.
+- Suggest verifying the result with a drift check (read-only) if the user wants confirmation that everything is now in sync.
+- Do not paste the raw CLI output unless the user explicitly asks.
 - Match the user's language.`,
                 },
             ],