@dforge-core/dforge-mcp 0.2.43 → 0.2.45

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

@@ -78,7 +78,7 @@ A report has a `label`, a `description`, a `datasets` map, a `layout` object (`{
 - `query.columns` — column codes; supports dot navigation (`customer.name`).
 - `query.filter` — canonical filter (`{c,o,v}` or `{g,i:[...]}`); use `@param_code` to reference a parameter.
 - `query.sort` — `[{ c, d }]` where `d` ∈ `asc | desc`.
-- `columnsDef` — optional per-column display overrides (`{ label, visible, width }`).
+- `columnsDef` — optional per-column display overrides (`{ label, fieldTypeCd, format, width }`; each key replaces the projected value). `label` is a literal and wins over a translated header. `visible` is accepted but read by nothing. `baseDatatypeCd` is read only where the dataset projects no columns of its own.
 
 ### Stored procedure dataset (developer path)
 
@@ -110,6 +110,9 @@ Key differences from entity datasets:
   **override** — `report.run` projects `dForge.sp_column`, and `columnsDef` only restyles it.
   A function returning an unnamed `SETOF <composite>` or a bare scalar declares no column
   names, so that one needs an explicit `columns` block in `logic/stored_procedures.json`.
+  Leave `label` out of `columnsDef` to keep the column's translated header: result-column headers
+  translate under the procedure, `storedProcedures.<sp_cd>.columns.<column_cd>.label`
+  (see `references/translations.md`), and every dataset bound to the procedure shows it.
 - Params work exactly as they do for an entity dataset, and `datasetType` makes no difference: declare them at report level (`parameters`) or on the dataset (`params`). Report level wins on a code collision.
 - **The parameter code must match the procedure's declared `paramCd` exactly.** `report.run`
   resolves each argument by that code alone — no prefix is added or stripped — so a report
@@ -159,8 +162,10 @@ $$;
 - `paramCd` is capped at 50 characters, and a declared `fieldTypeCd` must be a real one —
   both are checked at install, because binding the SP in the report editor copies them
   into report params.
-- `RETURNS TABLE (...)`.
+- `RETURNS TABLE (...)`. In `LANGUAGE plpgsql` with `RETURN QUERY`, each selected column must match its declared type exactly: a `varchar` column returned as `text` fails with "structure of query does not match function result type". Cast in the select (`c.account_name::text`).
 - Use the module's schema prefix (`crm.rpt_*`) and `STABLE` volatility.
+- **A function that returns one row: declare `ROWS 1`.** Install adds `SET search_path` to the function, which stops Postgres from inlining it, so the planner falls back to its default estimate of 1000 rows and a join on the function can turn a 5-second report into a 20-minute one. `ROWS 1` (or a realistic estimate) on each table function the report calls restores the plan.
+- **Every `logic/reports/*.sql` runs at every install**, as the install's database user. Don't create or replace the function by hand under another user while experimenting: the next install fails with "must be owner of function". Try SQL in a transaction you roll back, and let install own the functions.
 - **Security is your responsibility, and the function has no context to work from**: it is not
   told the folder or the user, so an SP dataset cannot be row-level scoped the way a `"Q"`
   dataset is. Use `"Q"` for anything that must be filtered per user, and keep `"S"` for
@@ -194,6 +199,7 @@ granted on. Keyed by stored-procedure code, which may not contain a dot.
 - **`params`** is the call signature, in order — omit it for a zero-argument function.
 - **`columns`** is optional; without it install derives the result columns from the
   function's `RETURNS TABLE (…)`.
+- A result column's `baseDatatypeCd` is a platform base type code: `string`, `number`, `bool`, `date`, `timestamp`, `time`, `guid`, `json`, `link`, `set`, `binary`, `xml`, `culture`. Not `datetime`, `boolean`, `integer` or `text`: an unknown code fails install with a bare foreign-key error on `sp_column`, which validate does not catch yet.
 - A result column may name a **`domain`** (`domain_cd` or `module_cd.domain_cd`) instead of
   `fieldTypeCd` / `baseDatatypeCd` / `params`: a status the function returns then shows its
   labels without restating the entity's option list. Naming a domain and restating any of

package/skills/dforge-mcp-author/references/schema-import.md

@@ -111,7 +111,7 @@ Using the converted entities, generate the full module package:
 4. **`ui/menus.json`** — grouped logically (group related entities under section nodes)
 5. **`ui/folders.json`** — root folder with all entities listed
 6. **`security/roles.json`** — at least `module.admin` (SIUDC on everything) and `module.user` (SIU on main entities)
-7. **`translations/en-US.json`** — labels for all entities, fields, views, menus, actions, roles, folders
+7. **English labels in the definitions** — a short `description` on every entity, field and role, a `label` on every view, menu and action. No `translations/en-US.json`: install skips it. Translation files only for the locales in `supportedLocales` (`dforge_translation_sync`)
 8. **`seed-data/`** — if the source had enum/lookup tables converted to entities, generate seed data for them
 
 ### Step 8: Generate IMPORT_NOTES.md

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

@@ -16,7 +16,7 @@ Lives in: `security/roles.json`
 
 Role codes use a `module.role` naming pattern (e.g. `crm.admin`, `crm.sales-rep`).
 
-> **Role display name & translations.** Each role has exactly two keys: `description` and `rights` (`roles.schema.json` is `additionalProperties: false` — **do not** add a `label` here). `description` is the English fallback display name. The **localized** display name lives in the translation files as `roles.<code>.label`, keyed by the module-qualified role code, and is **completeness-enforced**: every role must have a `roles.<code>.label` in every `translations/<locale>.json` (including the `en-US` base) or install fails. See `translations.md`.
+> **Role display name & translations.** Each role has exactly two keys: `description` and `rights` (`roles.schema.json` is `additionalProperties: false` — **do not** add a `label` here). `description` is the English display name — keep it a short label ("Storekeeper"), not an explanation, since it is what the English UI shows. The **localized** display name lives in the translation files as `roles.<code>.label`, keyed by the module-qualified role code, and is **completeness-enforced**: every role must have a `roles.<code>.label` in every non-English `translations/<locale>.json` or install fails. There is no English translation file. See `translations.md`.
 
 Example:
 

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

@@ -2,9 +2,33 @@
 
 dForge modules support multi-language translations for user-facing labels — entity names, field labels, view titles, folder names, menu items, action labels and params, and report params/dataset captions.
 
-Lives in: `translations/<locale>.json` (e.g. `translations/en-US.json`, `translations/de-DE.json`)
+Lives in: `translations/<locale>.json` for each **non-English** locale (e.g. `translations/de-DE.json`, `translations/uk-UA.json`)
 
-Locale codes use the `ll-CC` format (language-country): `en-US`, `de-DE`, `fr-FR`, `es-ES`, etc.
+Locale codes use the `ll-CC` format (language-country): `de-DE`, `uk-UA`, `fr-FR`, `es-ES`, etc.
+
+## English is the base — and it lives in the definitions
+
+Install **never reads** `translations/en.json` or `translations/en-*.json` (`ModulePackage.ReadTranslationFiles` skips them). The English UI shows the text written in the definitions themselves, so an English-only module ships **no** `translations/` folder, and a translated module ships one file per locale in `supportedLocales` and nothing for English. An `en-US.json` is dead weight: its labels are never applied, and the English UI keeps showing whatever the definitions say — which is how a module ends up displaying long service descriptions as labels. `dforge_module_validate` warns about such a file; `dforge_translation_sync` refuses to write one.
+
+Where each object's English text lives (what install shows, `label ?? description ?? code` where both exist):
+
+| Object | English text | Notes |
+|---|---|---|
+| Entity | `description` in `entities/<e>.json` | |
+| Field | `description` on the field | trait columns take theirs from the trait |
+| Data view | `label`, else `description` | with both, `description` is the tooltip |
+| Folder | `label`, else `description` | |
+| Menu / menu item | `label`, else `description` | |
+| Action | `label`, else `description` | an action param: its `description` |
+| Report | `label`, else `description` | |
+| Stored procedure | `description`; a result column: its `label` | |
+| Print template | `description` | `label` is rejected by the schema |
+| Setting | `description` | |
+| Role | `description` | `label` is rejected by the schema |
+| Column domain | `description` | |
+| Register | `label` | |
+
+Keep these short **labels** — "Product", "Storekeeper" — not explanations. Notes such as a legacy table name or "(in Ukrainian)" belong in docs or comments: whatever the field holds is the UI text.
 
 ## Structure
 
@@ -83,7 +107,8 @@ Translation files mirror the module's content structure. Each translatable objec
 | `views` | Data view labels and descriptions (`label`, `desc`) | View codes (keys from `ui/data_views.json`) → `{ label, desc }` |
 | `menus` | Menu node labels (root + nested items) | Menu root key → `{ label, items: { item_code: { label } } }` matching `ui/menus.json` structure |
 | `actions` | Action labels, descriptions, param labels **and param dropdown option labels** | Action codes (keys from `ui/actions.json`) → `{ label, desc, params: { param_cd: { label, options: { value: … } } } }` |
-| `reports` | Report dataset captions, param labels **and param dropdown option labels** | Report codes → `{ datasets: { ds_cd: { caption } }, params: { param_cd: { label, options: { value: … } } } }` |
+| `reports` | Report `label`, `desc`, dataset captions, param labels **and param dropdown option labels** | Report codes → `{ datasets: { ds_cd: { caption } }, params: { param_cd: { label, options: { value: … } } } }` |
+| `storedProcedures` | Result-column headers of a stored procedure (`logic/stored_procedures.json`), shared by every report bound to it | Procedure codes → `{ columns: { column_cd: { label } } }` |
 | `entities.<e>.constraints` | Check/unique constraint violation messages (opt-in — warned, not enforced) | Constraint codes → `{ message }` under the owning entity |
 | `messages` | DSL `info` / `warn` / `error` / `exit` texts (opt-in — warned, not enforced) | Exact English text → translated text |
 | `entities.<e>.fields.<f>.options` | Dropdown/radio/flags **option labels** (opt-in) | Option `value` → localized label (string) or `{ label, icon, color }` |
@@ -110,7 +135,7 @@ A check/unique constraint declares a user-facing `message` in the entity JSON (`
 
 ### Dropdown option labels ARE translatable (opt-in)
 
-The `options` on a `dropdown`/`radio`/`flags` column are the **base (fallback) labels**. To translate the labels a user actually sees, add an `options` map next to the field's `label`, keyed by the option's **value** (the stored code):
+The `options` on a `dropdown`/`radio`/`flags` column are the **base (fallback) labels**, and they are the English UI — write plain English there (`"Active"`), never a bilingual `"Active (Актив)"`. To translate the labels a user actually sees, add an `options` map next to the field's `label`, keyed by the option's **value** (the stored code). Prefer the **string** form (`"active": "Активний"`): the `{ label, … }` form is valid, but the VS Code extension's translation panel counts it as missing, and `module validate` does not check option translations at all. An option list several columns share belongs in a column domain, translated once under `domains.<code>.options`.
 
 ```json
 "entities": {
@@ -203,15 +228,14 @@ Role labels are **required and localized** (this changed — older docs said rol
 ```
 
 - **Keys are the role codes** from `security/roles.json` — already module-qualified (e.g. `crm.admin`, `crm.sales-rep`). They match `module_role.name`.
-- **Value is `{ "label": ... }`** — the localized display name. It supersedes the `description` from `roles.json` at runtime; `description` remains the English fallback if a role has no translation entry.
-- **Completeness is enforced.** `TranslationCompletenessValidator` requires `roles.<code>.label` for **every** role in `security/roles.json`, in **every** translation file — including the `en-US` base. A missing role label fails install with `Label for role '<code>'.` So ship a `roles` block with a label for each role in **each** `translations/<locale>.json` (en-US + every locale in `supportedLocales`).
+- **Value is `{ "label": ... }`** — the localized display name. It supersedes the `description` from `roles.json` in that locale; `description` is the English text.
+- **Completeness is enforced.** `TranslationCompletenessValidator` requires `roles.<code>.label` for **every** role in `security/roles.json`, in **every** translation file install reads — each locale in `supportedLocales`. A missing role label fails install with `Label for role '<code>'.` English needs nothing here: it is the role's `description`.
 
 ### Sections that are NOT translated (write-time only)
 
-- `settings` — completeness *is* checked by the validator when listed in `manifest.supportedLocales` (so you'll be forced to ship `settings.<cd>.label` for each declared locale), but the registrar doesn't display those translated labels at runtime. The English `label` in `settings.json` is what users see today.
-- `print_templates` — not currently consumed by the registrar. Template labels come from `ui/print_templates.json`.
+- `print_templates` — not consumed by the registrar: a template row has no translatable resource. Its name is the `description` in `ui/print_templates.json` in every language. If you include the section, install succeeds and ignores it.
 
-If you include these sections, the install succeeds (they're silently ignored) — but you won't see localized output for them, so don't expect it.
+`settings` **is** translated: completeness is checked for each declared locale (ship `settings.<cd>.label`), and the setting's English text is its `description` in `settings.json` — the registrar never reads a `label` there.
 
 ## German example (de-DE)
 
@@ -261,7 +285,7 @@ If you include these sections, the install succeeds (they're silently ignored)
 
 ## Manifest declaration
 
-Non-English locales are declared in `supportedLocales` (an array of `ll-CC` tags) — **not** a `translations` object. The manifest schema has no `translations` key and rejects it (`additionalProperties: false`). Translation files are auto-discovered at `translations/<locale>.json`. Ship `translations/en-US.json` as the English base, but do **not** list `en`/`en-US` in `supportedLocales` — it covers the non-English locales only (the schema rejects `en`/`en-US` entries).
+Non-English locales are declared in `supportedLocales` (an array of `ll-CC` tags) — **not** a `translations` object. The manifest schema has no `translations` key and rejects it (`additionalProperties: false`). Translation files are auto-discovered at `translations/<locale>.json`. Do **not** list `en`/`en-US` in `supportedLocales` and do not ship an English file — English is the definitions' own text (see above); the schema rejects `en`/`en-US` entries.
 
 ```json
 "supportedLocales": ["de-DE", "fr-FR"]
@@ -269,20 +293,24 @@ Non-English locales are declared in `supportedLocales` (an array of `ll-CC` tags
 
 Every listed locale MUST have a matching `translations/<locale>.json` with a label for each translatable resource, or install fails completeness validation.
 
+### Stored-procedure column headers
+
+A result column's header belongs to the procedure, not to a report. `module pack` / `module validate` require one `storedProcedures.<sp_cd>.columns.<column_cd>.label` per declared column for each non-English supported locale; install only warns (also when a translation names a column the module lacks). A dataset's `columnsDef` label is a literal and overrides it, so leave the label out to keep the column translated.
+
 ## Rules
 
-1. **Always provide `en-US`** as the base language. Other languages fall back to it for missing keys.
-2. **Locale format is `ll-CC`** (e.g. `en-US`, `de-DE`, `fr-FR`) — language code + country code, hyphen-separated.
-3. **Translate everything user-visible**: entity labels, every field label (including trait-provided fields like `created_date`, `last_updated`), view names, menu items, action labels, **role labels (required — completeness-enforced, `roles.<code>.label` for every role in every locale incl. en-US)**, setting labels, folder names.
+1. **English is the definitions' text** — no `en-US.json`. Write a short English label into each definition (see the table above); other languages fall back to it for missing keys.
+2. **Locale format is `ll-CC`** (e.g. `de-DE`, `uk-UA`, `fr-FR`) — language code + country code, hyphen-separated.
+3. **Translate everything user-visible**: entity labels, every field label (including trait-provided fields like `created_date`, `last_updated`), view names, menu items, action labels, **role labels (required — completeness-enforced, `roles.<code>.label` for every role in every declared locale)**, setting labels, folder names.
 4. **Include virtual columns** (references, sets, formulas) in field translations — they appear in the UI just like physical columns.
 5. **Menu translations mirror the `ui/menus.json` structure** — root key → `items` → nested items.
-6. **Missing keys fall back** to the `en-US` value, then to the raw code name. So it's safe to ship partial translations — untranslated items show in English rather than breaking.
+6. **Missing keys fall back** to the definition's English text, then to the raw code name. So it's safe to ship partial translations — untranslated items show in English rather than breaking.
 7. **Don't translate column codes** — only the `label` values. Codes stay as-is in all languages.
 8. **File naming**: `translations/<locale>.json` (e.g. `de-DE.json`) — each non-English file must match a locale listed in `supportedLocales`.
 9. **Constraint messages are opt-in** — localize them under `entities.<e>.constraints.<c>.message` when you want a per-locale violation message; otherwise the base `message` from the entity JSON is used. Missing overrides warn (non-fatal), they don't fail install. See "Constraint violation messages ARE translatable" above.
 
 ## When to create translations
 
-- **Always** create `translations/en-US.json` — even for English-only modules. It ensures all labels are explicitly declared rather than derived from column codes.
-- **On request** create additional languages. The LLM can generate translations from the `en-US` file — the structure is identical, only `label` and `desc` values change.
+- **Never** create `translations/en-US.json` — install skips it. Give every definition a short English label instead, so nothing falls back to a column code.
+- **On request** create additional languages: declare them in `supportedLocales` and run `dforge_translation_sync`, which seeds each file from the definitions' English text for you to translate in place.
 - **Include all fields** in each language file, including trait-provided fields (`created_date`, `last_updated`, `created_by`, etc.) — users see these columns and they need labels.

package/skills/dforge-mcp-author/references/validation-checklist.md

@@ -162,8 +162,8 @@ For each action:
 
 ## Translations
 
-- [ ] `translations/en-US.json` exists
-- [ ] Has `entities` section with `label`, `desc`, and `fields` for every entity
+- [ ] **No** `translations/en.json` / `en-*.json` — install skips them. English is each definition's own short label (entity/field/role/setting `description`, view/menu/action/report `label`)
+- [ ] Each `translations/<locale>.json` (one per `supportedLocales` entry) has an `entities` section with `label`, `desc`, and `fields` for every entity
 - [ ] Every field (including trait-provided: `created_date`, `last_updated`, etc.) has a `label`
 - [ ] Has `views` section with labels for every data view
 - [ ] Has `menus` section matching the `ui/menus.json` structure
@@ -172,7 +172,6 @@ For each action:
 - [ ] (Optional) Constraint messages localized under `entities.<e>.constraints.<c>.message` — opt-in; a missing override for a declared `supportedLocales` entry warns (surfaced by `dforge_module_validate` and at install) but does not fail install
 - [ ] Has `settings` section with labels for every setting (if settings exist)
 - [ ] Has `folders` section with label for the root folder
-- [ ] Additional language files (if any) have the same structure as `en-US.json`
 - [ ] Manifest `supportedLocales` lists every non-English locale that has a `translations/<locale>.json` file (English is not listed)
 
 ## Versioning

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

@@ -36,12 +36,15 @@ flags, or column patterns.
 | Suggest a value when another field is edited (a reaction), incl. from a bridge module | `dforge://reference/reactions` | `dforge://schema/entity`, `dforge://schema/deps` |
 | Add a trait | `dforge://reference/traits` | — |
 | Add a number sequence | `dforge://reference/number-sequences` | — |
+| Add an accumulation register (`A` column, `registers.json`) | `dforge://reference/registers` | `dforge://schema/registers` |
+| Edit the manifest (version, `supportedLocales`, dependencies, `entities` map) | `dforge://reference/manifest` | `dforge://schema/manifest` |
 | Add a grid / list view | `dforge://reference/data-views`, `dforge://example/ui/data_views.json` | — |
 | Add a matrix (pivot) view | `dforge://reference/data-views` (§Matrix), `dforge://example/matrix-budget/ui/data_views.json`, `dforge://example/matrix-budget/entities/budget_line.json` | — |
 | Add kanban / calendar / tree-grid / master-detail | `dforge://reference/data-views` | `dforge://schema/data-views` |
 | Hide columns from a user type (column-level security) | `dforge://reference/security` (§Column-level security), `dforge://example/column-security/entities/product.json`, `dforge://example/column-security/ui/folders.json` | — |
 | Add a menu | `dforge://reference/menus`, `dforge://example/ui/menus.json` | — |
 | Add an action | `dforge://reference/action-dsl`, `dforge://example/logic/actions/mark_done.dsl`, `dforge://example/ui/actions.json` | `dforge://docs/dsl` |
+| Email a file the script builds, or ship saved values / a PDF preview for an action's dialog | `dforge://reference/action-dsl` (§Email and §PDF and file output: `sendEmail` attachments, `attachText`, `attachBase64`; §Registering the action: `paramSets`, `previewTemplate`) | `dforge://docs/dsl` |
 | Share helpers between actions, or call another module's functions | `dforge://reference/action-dsl` (§Function libraries): `logic/functions/*.dsl`, imports in `deps/<module>.json` | `dforge://schema/deps` |
 | Add a trigger | — | `dforge://schema/triggers`; condition syntax in `dforge://docs/dsl` |
 | Add a scheduled job | `dforge://reference/jobs` | `dforge://schema/jobs` |
@@ -115,6 +118,10 @@ Enough to author inline; load the linked reference for the full detail.
 - **Manifest:** non-English locales go in `supportedLocales` (`ll-CC`, never
   `en`/`en-US`); there is no `translations` manifest key. `security` has both
   `roles` and `folders`. → `manifest`
+- **English is the definitions' text:** install skips `translations/en*.json`, so
+  never create one. Give every entity, field, role and setting a short
+  `description` and every view, menu, action and report a short `label` — that
+  is what the English UI shows. → `translations`
 - **Seed data:** explicit numeric PKs under `{entity}_id`; parents before
   children via the `NN-` prefix. Use `dforge_seed_add`.
 
@@ -160,6 +167,7 @@ approval, then patch. Reach for the **composite tools first**:
 - roll-up total → `dforge_entity_rollup_add`
 - status column → `dforge_entity_status_add`
 - plain scalar → `dforge_entity_field_add`
+- change an existing field (label, flags, type, …) → `dforge_entity_field_modify`
 
 **Field batching rule** — the only Phase 1 exception to one-at-a-time. A field
 is batchable only if ALL of: scalar primitive (string/integer/decimal/boolean/
@@ -285,7 +293,8 @@ stated trigger; every report's params sit on a dataset.
 ## Phase 4 — Polish (mostly optional)
 
 - **Settings** — `dforge_setting_add` per configurable value the user asked for.
-- **Translations** — run **`dforge_translation_sync`**. It generates every
+- **Translations** — only for the locales in `supportedLocales`; English needs
+  no file. Run **`dforge_translation_sync`**. It generates every
   required key from the module's own contents, never overwrites existing
   translated text, and fills the **role labels that are completeness-enforced at
   install**. Run it after any entity/view/role change, and always before Phase 6.

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

@@ -78,9 +78,9 @@ formula column shape; flags letters (`V I E M H` only); every entity has a
 default grid and `dataSources` at root with `"order"` as a string array; menu
 leaves use `dataViewCode` and bare icon names; every entity in at least one
 role's rights; action `script` values are bare filenames; seed PKs numeric with
-parents first; a `translations/<locale>.json` for every `supportedLocales` entry
-**plus** the `en-US` base, each carrying a label for every trait-provided field
-and every role.
+parents first; a `translations/<locale>.json` for every `supportedLocales` entry,
+each carrying a label for every trait-provided field and every role. No English
+file — install skips `en*.json`; English is the definitions' own short labels.
 
 If translations are thin, run **`dforge_translation_sync`** now rather than
 hand-patching — it fills exactly the keys install requires.
@@ -156,6 +156,34 @@ package — fix the referenced files, report what changed, and immediately re-ru
 validate → pack → install. Keep sign-off for product/design choices or genuinely
 ambiguous fixes.
 
+**If install hangs, or fails with a bare HTTP 500 or 400 "deadlock":** look for
+a lock before touching the module. An install's `ALTER TABLE` waits behind any
+open transaction on the module's tables — an idle `psql` session, an ad hoc
+read left open, a script that never commits — and waits without a message,
+for an hour or more. Check `pg_stat_activity` for a blocked `ALTER` and the
+session holding it. Never install while scripts hold transactions on the
+module's tables; run ad hoc scripts in autocommit.
+
+**If install times out on the client while rebuilding a register cache:** the
+server goes on and finishes (an analytic cache over 1.5 million postings took
+about 18 minutes). Check the server log or the cache before installing again.
+
+**Same version installed "successfully" but nothing changed:** a re-install of
+the same `version` is skipped (`isEmpty: true`). Bump the version, or pass
+`--force` on a dev tenant.
+
+**Local dev stack pitfalls:**
+- After installing into a local docker setup, restart `dforge-api` if the UI
+  still shows the old metadata; its cache can stay stale.
+- The tenant URL is `http://<tenant>._.localhost:5179`. `<tenant>.localhost`
+  and `<tenant>_.localhost` sign into **another** tenant.
+- "no token for tenant X": the CLI session expired (a token lasts about an
+  hour). Run `dforge-cli auth login --url <tenant url>`.
+- "tenant at db_schema_version … is ahead of this binary" after rebuilding the
+  platform: install through the server with `--url`.
+- Don't keep scaffold copies of a module (same `code`, another `moduleId`)
+  anywhere a folder publish can pick them up.
+
 **If install fails on auth (401/403) or connectivity (refused):** that is
 credentials/connectivity, NOT a module defect. Tell the user to verify
 `DFORGE_URL` and `DFORGE_TOKEN`. **Do not backtrack** to earlier phases.

package/skills/dforge-mcp-author/examples/column-security/translations/en-US.json

@@ -1,35 +0,0 @@
-{
-	"entities": {
-		"product": {
-			"label": "Product",
-			"fields": {
-				"name": { "label": "Product Name" },
-				"sku": { "label": "SKU" },
-				"quantity": { "label": "Quantity On Hand" },
-				"cost_price": { "label": "Cost Price" },
-				"sale_price": { "label": "Sale Price" },
-				"margin": { "label": "Margin" }
-			}
-		}
-	},
-	"folders": {
-		"warehouse": { "label": "Warehouse" },
-		"finance": { "label": "Finance" }
-	},
-	"roles": {
-		"column_security.storekeeper": { "label": "Storekeeper" },
-		"column_security.accountant": { "label": "Accountant" }
-	},
-	"views": {
-		"product_grid": { "label": "Products" }
-	},
-	"menus": {
-		"product_menu": {
-			"label": "Products",
-			"items": {
-				"catalog": { "label": "Catalog" },
-				"all_products": { "label": "Products" }
-			}
-		}
-	}
-}