@dforge-core/dforge-mcp 0.2.4 → 0.2.5

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/CHANGELOG.md CHANGED
@@ -4,6 +4,87 @@ All notable changes to `@dforge-core/dforge-mcp`. This project uses semver-ish
4
4
  `0.1.0-rc.N` pre-release tags; the published version is set at publish time via
5
5
  the release workflow, so committed `package.json` versions are placeholders.
6
6
 
7
+ ## 0.2.5
8
+
9
+ Catches up with the platform's parameter-options work (dForge-core 1.20.0). A dropdown
10
+ parameter can now carry real labels, and — better — borrow the shared list its target
11
+ column already uses. Both were undocumented here, and one reference actively said the
12
+ first was impossible.
13
+
14
+ ### Changed — `translations.md` said param option labels didn't exist
15
+
16
+ The section table listed `actions` / `reports` params as translating `{ label }` and
17
+ nothing else, which was accurate when written: parameters had no schema location for a
18
+ per-choice label at all. An author who followed it concluded — correctly, at the time —
19
+ that a dropdown param showing `bank_transfer` instead of "Bank transfer" was unfixable.
20
+ The platform added the slot, so the table now shows
21
+ `params: { param_cd: { label, options: { value: … } } }` for both sections, and a new
22
+ **"Action / report PARAM option labels ARE translatable"** section documents the
23
+ value-keyed, partial-override shape (identical to field options) plus the two things that
24
+ trip authors up: base labels must exist in the DSL first, and a domain-backed param
25
+ shouldn't be translated here at all.
26
+
27
+ ### Added — `domain <domainCd>` param form
28
+
29
+ `action-dsl.md` and `dsl-reference.md` gain the parameter form that borrows a column
30
+ domain:
31
+
32
+ ```
33
+ params:
34
+ payment_method: domain payment_method required "Payment method for this batch"
35
+ status: domain fin.doc_status optional "Status"
36
+ ```
37
+
38
+ Both now lead with it and frame inline `options=` as the narrow case. The reason is
39
+ duplication, not typing: a param whose value gets written to a domain-backed column used
40
+ to restate that column's enum, so the same list was authored twice, translated twice, and
41
+ free to drift — and a param option whose code isn't on the column is a value the grid
42
+ can't label. `column-domains.md` gains a matching **"Using a domain in an action / report
43
+ param"** section, and `reports.md` documents the JSON equivalent
44
+ (`{"domain": "fin.doc_status"}`, mutually exclusive with `fieldTypeCd`).
45
+
46
+ Also documented: the param keeps its **own** caption (only the choices come from the
47
+ domain), install materializes just the domain's `fieldTypeCd` (a parameter has no
48
+ storage, so datatype and sizing don't apply), and nothing may follow the description —
49
+ `options=`, `min=` and friends are a compile error there, the same authority rule columns
50
+ already had.
51
+
52
+ ### Changed — labeled `options=` in the DSL references
53
+
54
+ The dropdown row in `dsl-reference.md` showed only `options=low,medium,high`, which is
55
+ exactly the shape that renders raw codes in every locale. It now shows the labeled forms
56
+ (`options=[low:Low, medium:Medium, high:High]`, and the JSON object form for icon/colour),
57
+ with the wrapping rule spelled out: the trailing `key=value` scan is whitespace-delimited,
58
+ so a label containing a space needs `[ ]` or quotes around the list.
59
+
60
+ `resources/docs/conventions.md` (vendored from dForge-core) gains the same guidance
61
+ inline. It was **not** re-synced wholesale: the vendored copy has diverged *forward* from
62
+ core in ~15 places — seed-data `cuid`-is-int8 warnings, mandatory-flag `M` semantics,
63
+ rights characters — so a straight `cp` (what `VENDOR_REFS=1` does) would silently drop
64
+ them. That drift is worth reconciling deliberately, in its own pass.
65
+
66
+ ### Fixed — `dforge_module_validate` rejected a domain-backed report param
67
+
68
+ `resources/schemas/reports.schema.json` required `fieldTypeCd` and had no `domain` key, so
69
+ the very form the docs above now recommend failed validation. `@dforge-core/metadata` is
70
+ bumped to `^0.0.14` and the 16 vendored schemas re-synced, which lands the new `paramDef`:
71
+ `domain` is accepted (`domain_cd` or `module_cd.domain_cd`), `fieldTypeCd` is no longer
72
+ required — a param declaring neither installs as `text` — and the one rejected combination
73
+ is declaring both. Action params were never affected (the DSL has no JSON schema).
74
+
75
+ ### Changed — dependency bumps
76
+
77
+ `@dforge-core/dforge-cli` `^0.2.12` → `^0.2.13`, `@dforge-core/metadata` `^0.0.13` →
78
+ `^0.0.14`, and the dev toolchain moves to `vitest` 4 and `@types/node` 26. A
79
+ `pnpm-workspace.yaml` pins the pnpm build allowlist and exempts the freshly-published
80
+ dForge packages from `minimumReleaseAge`, which otherwise blocks installing them the day
81
+ they ship.
82
+
83
+ ### Known gap
84
+
85
+ `dforge_translation_sync` doesn't seed `options` maps for fields, domains or params —
86
+ authors write those keys by hand.
87
+
7
88
  ## 0.2.3
8
89
 
9
90
  Catches up with the platform's current-user work: `currentUserId()` exists now,