@dforge-core/dforge-mcp 0.2.16 → 0.2.17

package/CHANGELOG.md

@@ -4,6 +4,42 @@ All notable changes to `@dforge-core/dforge-mcp`. This project uses semver-ish
 `0.1.0-rc.N` pre-release tags; the published version is set at publish time via
 the release workflow, so committed `package.json` versions are placeholders.
 
+## 0.2.17
+
+A bridge module's `async: false` trigger **can** roll back its host module's write,
+and that is intended (platform issue #999). It is the same coupling a mandatory
+extension column already creates — mark one `M` and the host's own `data.insert`
+is refused with *"Missing required columns: …"* for a field the host knows nothing
+about. A bridge that can add a required field can add a required *condition*, and
+cross-module invariants are what bridge modules exist to enforce.
+
+What changed platform-side is that the veto now says who issued it, so the guidance
+here says what to point it at.
+
+### Changed — `async: false` is a refusal mechanism, not a reaction
+
+`dforge_trigger_add`'s `async` description and `dforge-module-build` Phase 2b both
+said only that a failure "rolls back the original change" — true, and read by an
+authoring agent as a footnote about transactions rather than as the decision it is.
+Both now state that the rollback reaches **another module's** entity, and the rule
+that follows: pick `async: false` to enforce an invariant, not merely to react,
+because a bug in the action blocks the host's workflow exactly as effectively as a
+real violation. Keep such an action to the check and put the rest behind
+`try`/`catch` or in an `async: true` trigger.
+
+### Changed — a blocked write names the module that blocked it
+
+Trigger failures now report error code **`TRIGGER_ACTION_FAIL`** (the other action
+phases keep `ACTION_EXECUTION_FAIL`), rendered as *Blocked by "crm-fin" (automation
+"on_invoice_posted"): Credit limit exceeded.* in the caller's locale, with the
+action's own `error()` text passed through. The module named is the one that
+**declared the trigger**, not the one owning the action — a bridge routinely
+subscribes its own trigger to an action living elsewhere, and what refused the write
+is the subscription. Nothing to change in a module for this; it is what an author
+should expect to see when their trigger fires.
+
+Nothing is rejected that was accepted before — `dforge_module_validate` is unchanged.
+
 ## 0.2.16
 
 Entity views — the platform's **column-level security** — became reachable from a

package/dist/server.js

@@ -31002,7 +31002,7 @@ var import_node_crypto = require("crypto");
 var fs2 = __toESM(require("fs"));
 var path2 = __toESM(require("path"));
 
-// node_modules/.pnpm/@dforge-core+dforge-cli@0.2.14/node_modules/@dforge-core/dforge-cli/dist/lib.mjs
+// node_modules/.pnpm/@dforge-core+dforge-cli@0.2.15/node_modules/@dforge-core/dforge-cli/dist/lib.mjs
 function buildManifest(opts, moduleId) {
   const today = (/* @__PURE__ */ new Date()).toISOString().slice(0, 10);
   const manifest = {
@@ -31214,7 +31214,7 @@ function buildZedSettings() {
 var fs = __toESM(require("fs"));
 var path = __toESM(require("path"));
 
-// node_modules/.pnpm/@dforge-core+metadata@0.0.18/node_modules/@dforge-core/metadata/dist/index.js
+// node_modules/.pnpm/@dforge-core+metadata@0.0.20/node_modules/@dforge-core/metadata/dist/index.js
 var AggType = {
   Sum: "sum",
   Count: "count",
@@ -36248,7 +36248,7 @@ var triggerAddSchema = {
     "STATIC params only \u2014 the literal values given here. Nothing is injected at runtime; there is no record_id param. The affected record arrives as record context ([field]), its pre-change values as old[field]."
   ),
   async: external_exports.boolean().default(true).describe(
-    "When true (the platform default), the action runs in background \u2014 recommended for slow actions. When false, it runs in the caller's transaction, so a failing action ROLLS BACK the user's original write."
+    "When true (the platform default), the action runs in background \u2014 recommended for slow actions. When false, it runs in the caller's transaction, so a failing action ROLLS BACK the user's original write. That applies to a trigger on ANOTHER module's entity too: a bridge module CAN veto its host's write, the same way a mandatory extension column already refuses one. So async:false is a refusal mechanism \u2014 pick it to enforce an invariant, not merely to react, because a bug in the action blocks the host's workflow just as effectively as a real violation. The rollback is reported to the user as TRIGGER_ACTION_FAIL, naming the blocking module and trigger."
   )
 };
 function triggerAdd(args) {

package/package.json

@@ -1,6 +1,6 @@
 {
 	"name": "@dforge-core/dforge-mcp",
-	"version": "0.2.16",
+	"version": "0.2.17",
 	"description": "MCP server for dForge module authoring. Exposes 34 scaffold/patch/validate/pack/install tools and schema resources so AI agents (Claude Code, Cursor, Zed) can create and ship dForge modules.",
 	"license": "MIT",
 	"homepage": "https://github.com/iash44/dForge-core",
@@ -35,8 +35,8 @@
 		"install-skills": "node scripts/install-skills.mjs"
 	},
 	"dependencies": {
-		"@dforge-core/dforge-cli": "^0.2.14",
-		"@dforge-core/metadata": "^0.0.18",
+		"@dforge-core/dforge-cli": "^0.2.15",
+		"@dforge-core/metadata": "^0.0.20",
 		"@modelcontextprotocol/sdk": "^1.30.0",
 		"zod": "^4.4.3"
 	},

package/resources/schemas/deps.schema.json

@@ -40,7 +40,7 @@
 				},
 				"columns": {
 					"type": "object",
-					"description": "Provider columns the consumer actually reads, writes, or joins on. Omit entirely for extension-only targets that touch no existing provider column.",
+					"description": "Provider columns the consumer actually reads, writes, or joins on. Omit entirely for extension-only targets that touch no existing provider column. A column your OWN 'extends' file adds to the provider needs no entry either — the platform exempts those and validates them separately — and a VIRTUAL extension field (columnType R/S/F: the lookup beside an FK, a reverse set, a formula) must never be listed at all: it is metadata, never a provider storage column, so no storage class can ever match and the install-time satisfaction check rejects the declaration. Declare the FK you add (e.g. trip_id), never the lookup beside it (trip).",
 					"additionalProperties": { "$ref": "#/definitions/columnContract" }
 				}
 			}

package/resources/schemas/manifest.schema.json

@@ -49,7 +49,7 @@
 		},
 		"schemaName": {
 			"type": "string",
-			"description": "Database schema name override (defaults to module code, system modules use 'dForge')"
+			"description": "Database schema name override (defaults to module code, system modules use 'dForge'). Do NOT share one schema between modules that extend other modules' entities: an extension's columns live in \"{schemaName}\".\"{entity}_ext\", named for the schema rather than the module, and nothing records which module wrote a column — so install rejects a module that both shares its schema with another installed module and declares 'extends'. Leave unset (the module code, which is unique) for bridge modules."
 		},
 		"system": {
 			"type": "boolean",

package/resources/schemas/menus.schema.json

@@ -23,7 +23,7 @@
 				"folders": {
 					"type": "array",
 					"items": { "type": "string" },
-					"description": "Folder codes where this menu is available"
+					"description": "Flat folder codes this menu is linked to (module code for the root, module code + '_' + each nesting segment for children, e.g. 'logistics_all_trips'; the full path, the module-relative path, and a folder's own key when unique in the tree also resolve). Omit to link the menu to every folder the module declares. Scopes the folder-to-menu link only — every folder in ui/folders.json is created either way. A code matching no folder, or a key two branches share, fails the install."
 				},
 				"items": {
 					"type": "object",

package/resources/schemas/triggers.schema.json

@@ -50,7 +50,7 @@
 				"async": {
 					"type": "boolean",
 					"default": true,
-					"description": "When true (the default), the action runs in the background — the triggering transaction commits before the action starts. Recommended for slow actions (emails, external API calls); background failures are logged, not surfaced to the caller. When false, the action runs synchronously inside the same transaction as the triggering insert/update/delete: if the action fails (e.g. calls error()), the whole mutation rolls back and the error is returned to the caller — so an async:false trigger can undo the user's write. Keep async:false actions fast; they run on the request's transaction."
+					"description": "When true (the default), the action runs in the background — the triggering transaction commits before the action starts. Recommended for slow actions (emails, external API calls); background failures are logged, not surfaced to the caller. When false, the action runs synchronously inside the same transaction as the triggering insert/update/delete: if the action fails (e.g. calls error()), the whole mutation rolls back and the error is returned to the caller — so an async:false trigger can undo the user's write. That holds for a trigger on ANOTHER module's entity too (the bridge shape): a bridge can veto its host's write, the same way a mandatory extension column already refuses one. Use it to enforce an invariant, not merely to react — the error names the blocking module and trigger (code TRIGGER_ACTION_FAIL), and a bug in the action blocks the host's workflow just as effectively as a real violation. Keep async:false actions fast; they run on the request's transaction."
 				}
 			},
 			"additionalProperties": false

package/skills/dforge-module-build/SKILL.md

@@ -187,7 +187,13 @@ before committing, then `dforge_action_add`. One action per turn.
 
 **2b Triggers** reference actions that must already exist. `async: true` runs
 after the transaction commits (use for anything slow); `async: false` runs
-in-transaction, so a failure rolls back the original change.
+in-transaction, so a failure rolls back the original change — **including on
+another module's entity**. A bridge's `async: false` trigger vetoes its host's
+write, exactly as a mandatory extension column already refuses one, so pick it
+to enforce an invariant, not merely to react: a bug in the action blocks the
+host's workflow as effectively as a real violation. Keep such an action to the
+check itself and put everything else behind `try`/`catch` or in an
+`async: true` trigger.
 
 **2c Jobs** run as the system user with **no current record** — the action must
 not use `[field]` syntax. Wrap a record-context action in a thin job action that