@dforge-core/dforge-mcp 0.2.30 → 0.2.31

package/CHANGELOG.md

@@ -4,6 +4,19 @@ 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.31
+
+**`dforge://reference/formulas` showed check constraints in formula syntax**
+(dForge-core#1263). Its examples were `[quantity] > 0` and `[end_date] >= [start_date]`,
+but a check constraint's `expression` is copied into a PostgreSQL `CHECK (...)` as is. A
+module written from the reference passed `dforge_module_validate` and then failed the
+install with `syntax error at or near "["`. The reference now shows plain SQL over real
+column names, with `IS NULL` / `IS NOT NULL` instead of the formula engine's `= null`.
+
+- With `@dforge-core/dforge-cli` 0.2.24 or later, `dforge_module_validate` also reports
+  both mistakes as errors under `cli: check constraints`: a `[field]` reference, and a
+  comparison with `null`, which in SQL never fails the CHECK. An older CLI skips the check.
+
 ## 0.2.28
 
 **`dforge_module_validate` reported a clean module that `pack` then rejected**

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.23/node_modules/@dforge-core/dforge-cli/dist/lib.mjs
+// node_modules/.pnpm/@dforge-core+dforge-cli@0.2.24/node_modules/@dforge-core/dforge-cli/dist/lib.mjs
 function buildManifest(opts, moduleId) {
   const today = (/* @__PURE__ */ new Date()).toISOString().slice(0, 10);
   const manifest = {

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@dforge-core/dforge-mcp",
-  "version": "0.2.30",
+  "version": "0.2.31",
   "description": "MCP server for dForge module authoring. Exposes 35 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",
@@ -26,7 +26,7 @@
     "node": ">=18"
   },
   "dependencies": {
-    "@dforge-core/dforge-cli": "^0.2.23",
+    "@dforge-core/dforge-cli": "^0.2.24",
     "@dforge-core/metadata": "^0.0.30",
     "@modelcontextprotocol/sdk": "^1.30.0",
     "zod": "^4.4.3"

package/skills/dforge-mcp-author/references/formulas.md

@@ -246,14 +246,21 @@ In modules that use settings, formulas can reference setting values with `$[Sett
 
 ## Validation and CHECK constraints
 
-Check constraints use a subset of the formula grammar. The server parses them to AST and converts to SQL. Common patterns:
+A check constraint's `expression` is **not** a formula. It is copied verbatim into a
+PostgreSQL `CHECK (...)`, so write plain SQL over real column names — no `[brackets]`, and
+`IS NULL` / `IS NOT NULL` instead of the formula engine's null-safe `= null` / `!= null`:
 
 ```
-[quantity] > 0
-[end_date] >= [start_date]
-[email] LIKE '%@%'
+quantity > 0
+end_date IS NULL OR end_date >= start_date
+cancelled = false OR cancel_reason_id IS NOT NULL
 ```
 
+`module validate` rejects both formula habits: `[field]` fails the install with
+`syntax error at or near "["`, and `x != null` is never true in SQL, so the CHECK would
+always pass. The client pre-validates only a subset of SQL (comparisons, `AND`/`OR`/`NOT`,
+`IN`, `BETWEEN`, `IS [NOT] NULL`, arithmetic, regex `~`); the database enforces the rest.
+
 The constraint's `message` (the violation text shown to users) is **localizable** — add a per-locale override at `entities.<entityCd>.constraints.<constraintName>.message` in each `translations/<locale>.json`. The base `message` in the entity JSON is the fallback. See `translations.md` → "Constraint violation messages ARE translatable".
 
 ## Examples — full formula columns