@flusys/nestjs-entity-builder 9.1.0 → 9.1.2

package/README.md

@@ -9,13 +9,13 @@ Works on PostgreSQL and MySQL (via `SchemaDialectAdapterService`). Import `Entit
 - **Multi-tenant** (`databaseMode: 'multi-tenant'`): definitions, runtime tables, flows and flow executions all live in the tenant's database - the tenant is the only isolation the package enforces. Services resolved through `ModuleRef` (flow entity access) find the tenant through the request context: `MultiTenantDataSourceService` falls back to it when there is no request.
 - **Company feature** (`enableCompanyFeature`): changes nothing in the tables. Entity and field definitions, flows, their API keys and flow executions are tenant-wide - every company has the same schema and runs the same flows, and permission codes `entity_builder.entity.<code>.*` are global like other permission actions. A runtime table holds only the system columns (`id`, timestamps, soft delete and audit columns when enabled) plus the fields the designer defines; there is no automatic `company_id`, no company filter and no per-company unique.
 - **Scoping records to a company or branch is the entity designer's choice**: add fields such as `company_id` / `branch_id` (plain field codes, not reserved), then map them in the flow - `user.companyId` / `user.branchId` on insert, and the same value in the filter of every get / find / update / delete / lookup step that must stay inside the caller's company. Public and API-key runs have no signed-in caller, so such a flow takes the company from its input instead. A unique field is unique across the whole table.
-- IAM still applies per company: permission checks (`HAS_PERMISSION`, Check permission steps, entity permissions of flows running as the caller) use the caller's own company and branch.
+- IAM still applies per company: permission checks (`HAS_PERMISSION`, Check permission steps, a `permission` URL) use the caller's own company and branch.
 
 ## Endpoints (all POST)
 
 | Path | Purpose | Permission |
 | --- | --- | --- |
-| `entity-builder/entity-definitions/create-entity` | Create entity + table (+ initial fields) in one DDL transaction. `flowEndpoints` (any of the generic API controller's endpoints: `insert`, `insertMany`, `getById`, `getByIds`, `getAll`, `getByFilter`, `update`, `updateMany`, `bulkUpsert`, `delete`) also saves one ready-made flow for the entity after the commit - slug `<code-with-dashes>` (e.g. `customer-ticket`), named after the entity, `jwt` auth, runs as the caller (entity permissions apply), transactional when an endpoint writes - with one Request step per endpoint on its own path, `POST api-flows/<code-with-dashes>/<endpoint-in-kebab-case>` (e.g. `customer-ticket/get-by-ids`, `ENTITY_FLOW_PATHS`), each with its own body; there is no Request step on the flow's own URL. Each endpoint's steps are ids `<endpoint>_<step>` (e.g. `getById_record`) laid out one below the other. Single endpoints are Request -> entity step -> respond with its result; `getAll` / `getByFilter` take an optional equality filter per scalar field (`getByFilter` answers the first match or 404); `getByIds` takes `ids` (`in` filter); `insertMany` / `updateMany` / `bulkUpsert` have a `list` body type - the request body is the list of records itself (`[{ ... }, { ... }]`), each item checked against the entity fields (insert: the insert inputs; update many: `id` required, the rest optional; bulk upsert: all optional) - loop over `input` (up to 200) in one transaction and answer the saved records in order (`bulkUpsert` updates an item with an `id`, inserts one without). `flowTexts` (`names` of each endpoint's Request step, `inputLabels` for `id` / `ids` / `search`, `noMatchMessage`) carries the text written into the flow in the creator's language - English for anything left out. The flow is saved after the commit: when it fails the entity stays and the failure comes back in the response's `warnings` (`entity_builder.schema.warning.endpoint.flow.failed`, with the cause as a nested message ref), next to a failed permission set-up (`...follow.up.failed`). It is an ordinary flow the user can change or delete later. Needs `flow_definition.create` too; a slug already in use is a plan blocker | `entity_builder.entity_definition.create` |
+| `entity-builder/entity-definitions/create-entity` | Create entity + table (+ initial fields) in one DDL transaction. `flowEndpoints` (any of the generic API controller's endpoints: `insert`, `insertMany`, `getById`, `getByIds`, `getAll`, `getByFilter`, `update`, `updateMany`, `bulkUpsert`, `delete`) also saves one ready-made flow for the entity after the commit - slug `<code-with-dashes>` (e.g. `customer-ticket`), named after the entity, every Request step with `permission` access asking for the entity's own permission (`entity_builder.entity.<code>.create` for insert / insertMany, `.read` for the reads, `.update` for update / updateMany, `.create` AND `.update` for bulkUpsert, `.delete` for delete - the actions created with the entity), since a flow's access is its only gate, each write endpoint transactional and each read endpoint without a transaction - with one Request step per endpoint on its own path, `POST api-flows/<code-with-dashes>/<endpoint-in-kebab-case>` (e.g. `customer-ticket/get-by-ids`, `ENTITY_FLOW_PATHS`), each with its own body; there is no Request step on the flow's own URL. Each endpoint's steps are ids `<endpoint>_<step>` (e.g. `getById_record`) laid out one below the other. Single endpoints are Request -> entity step -> respond with its result; `getAll` / `getByFilter` take an optional equality filter per scalar field (`getByFilter` answers the first match or 404); `getByIds` takes `ids` (`in` filter); `insertMany` / `updateMany` / `bulkUpsert` have a `list` body type - the request body is the list of records itself (`[{ ... }, { ... }]`), each item checked against the entity fields (insert: the insert inputs; update many: `id` required, the rest optional; bulk upsert: all optional) - are one write step on the list itself (`<endpoint>_records`, `target: many`, `items: input`, each item's fields read as `loop.item.<field>`, up to `FLOW_LIMITS.MAX_WRITE_ITEMS`), all or nothing in one transaction, answering the saved records in order (`context.<endpoint>_records.items`; `updateMany` updates each item by its own `id` and fails on one that does not exist; `bulkUpsert` is an update with `onNotFound: insert` - it updates an item with an `id` and creates one without, or whose record is gone). Every Request body declares each field by its type: a choice with its options, a multi-select as a list of those choices (`itemType: choice`, or `string` without options), a relation or file as an id (`uuid`), JSON as an object; write endpoints also copy the field's own `validationRules` a body can check (`min` / `max` on numbers, `minLength` / `maxLength` on text), so a bad value is refused per field before any step runs; read filters check only the type. `flowTexts` (`names` of each endpoint's Request step, `inputLabels` for `id` / `ids` / `search`, `noMatchMessage`) carries the text written into the flow in the creator's language - English for anything left out. The flow is saved after the commit: when it fails the entity stays and the failure comes back in the response's `warnings` (`entity_builder.schema.warning.endpoint.flow.failed`, with the cause as a nested message ref), next to a failed permission set-up (`...follow.up.failed`). It is saved unpublished (`version` 0), so its URLs answer 404 until someone publishes it. It is an ordinary flow the user can change or delete later. Needs `flow_definition.create` too; a slug already in use is a plan blocker | `entity_builder.entity_definition.create` |
 | `entity-builder/entity-definitions/plan-create-entity` | Dry run of the above: the real `CREATE TABLE` SQL, nothing is created | `...entity_definition.create` |
 | `entity-builder/entity-definitions/plan-change` | Dry run of any change below: exact SQL + reverse SQL, data checks, blockers, warnings, affected flows. Plans count records (never show their values), so planning needs the permission that applies the change | `...entity_definition.update` (`...delete` for `drop_entity` / `purge_field`) |
 | `entity-builder/entity-definitions/apply-change` | Apply `add_field`, `update_field`, `deprecate_field`, `restore_field`, `update_entity`, `repair`. Answers the plan of what ran (`downSql` = the undo statements of what ran) plus `result` (the change's summary, e.g. repair's `fixed`) | `...entity_definition.update` |
@@ -24,13 +24,19 @@ Works on PostgreSQL and MySQL (via `SchemaDialectAdapterService`). Import `Entit
 | `entity-builder/entity-definitions/schema-history` | Every schema change with its SQL, failed attempts included | `...entity_definition.read` |
 | `entity-builder/entity-definitions/{get-all,get/:id,get-by-ids,get-by-filter}` | Metadata read (writes only through the endpoints above) | `...entity_definition.read` |
 | `entity-builder/field-definitions/{get-all,get/:id,get-by-ids,get-by-filter}` | Field metadata read | `...field_definition.read` |
-| `api-flows/:slug` | **Call a flow** (a virtual API) from its Request step on the flow's own URL. Access is the flow's own auth mode; the answer is what its `respond` node says |
-| `api-flows/:slug/:endpoint` | **Call one of the flow's other URLs**: runs from the Request step whose `path` is `endpoint`, checked against that step's own body. Same auth, rate limit and run-as as the flow's own URL | per flow: public / API key / any user / a permission |
-| `entity-builder/flows/{insert,update,delete,get-all,get/:id,...}` | Flow CRUD - every save is validated as a whole | `...flow_definition.*` |
+| `api-flows/:slug` | **Call a flow** (a virtual API) from its Request step on the flow's own URL. Access is that Request step's own (`config.authMode`; a step for other flows only answers 404); the answer is what its `respond` node says. Only the published version runs; a flow never published answers 404 |
+| `api-flows/:slug/:endpoint` | **Call one of the flow's other URLs**: runs from the Request step whose `path` is `endpoint`, checked against that step's own body, access, rate limit, transaction and time limit | per Request step: public / API key / any user / a permission |
+| `entity-builder/flows/{insert,update,delete,get-all,get/:id,...}` | Flow CRUD - every save is validated as a whole. `insert` creates the flow unpublished (`version` 0); `update` of a published flow saves into its `draft` (see **Versions**) | `...flow_definition.*` |
+| `entity-builder/flows/publish` | `{ id, note? }`: makes the draft live as the next version | `...flow_definition.update` |
+| `entity-builder/flows/{versions,version}` | `{ flowId }`: published versions, newest first; `{ flowId, version }`: one in full | `...flow_definition.read` |
+| `entity-builder/flows/{restore-version,discard-draft}` | Put an old version back into the draft / drop the draft | `...flow_definition.update` |
 | `entity-builder/flows/validate` | Check a draft without saving (errors block a save, warnings do not) | `...flow_definition.read` |
 | `entity-builder/flows/test-run` | Run a saved flow or an unsaved draft, with a per-node trace | `...flow_definition.test` |
-| `entity-builder/flow-api-keys/{create,list,revoke,delete}` | API keys of a flow (the key is shown once). `create` takes `{ flowId, name, expiresAt? }` (ISO, in the future; no zone = UTC); every key has `status` `active` / `revoked` / `expired`. Revoke and delete work whatever the flow's auth mode is | `...flow_definition.update/read` |
-| `entity-builder/flow-executions/{list,get}` | Run history | `...flow_definition.read` |
+| `entity-builder/flow-executions/{list,get}` | Run history; each run keeps the Request step it came in through (`endpointNodeId`, and `endpointPath` as it was then), and `list` filters by `status`, `trigger` (`webhook` / `test`) and `endpointNodeId` | `...flow_definition.read` |
+| `entity-builder/bundles/settings` | `{ readOnly, variables }`: whether the designer is locked here, and the names of the variables this environment defines | `...entity_definition.read` or `...flow_definition.read` |
+| `entity-builder/bundles/export` | `{ entityCodes?, flowSlugs? }`: entities and published flows as a bundle, with its `checksum` (see **Promoting between environments**) | `...entity_definition.read` + `...flow_definition.read` |
+| `entity-builder/bundles/plan-import` | Multipart: file `bundle` + `deprecateMissingFields?`: every step the import would run, in order, with each previewable step's real plan; nothing changes | `...entity_definition.create/update` + `...flow_definition.create/update` |
+| `entity-builder/bundles/apply-import` | Multipart: file `bundle` + `deprecateMissingFields?`, `confirm?`, `expectedChecksum?`, `expectedPlanChecksum?` (required with `confirm`): runs the plan; works while the designer is read-only | same as `plan-import` |
 
 `entity_builder.entity.*` is a wildcard grant covering every dynamic entity (seeded by `seed:admin`); it covers only dynamic entities, not the static schema-admin permissions (`entity_builder.entity_definition.*`, `entity_builder.field_definition.*`, `entity_builder.flow_definition.*`).
 
@@ -38,7 +44,7 @@ Works on PostgreSQL and MySQL (via `SchemaDialectAdapterService`). Import `Entit
 
 - **Every structural change is a plan first.** `plan-change` runs the same code as `apply-change` in a dry run (TypeORM SQL-memory mode), so the SQL you preview is the SQL that runs. Data is checked before anything changes: converting `TEXT` to `INTEGER` is refused while any value is not a whole number (with examples), a unique constraint is refused while duplicates exist, and a required field on a table with records needs a default/backfill value. Unsupported conversions are refused with the reason. MySQL has no `USING` clause, so on MySQL single select <-> multi select and text -> boolean are refused too (add a new field, copy the data, deprecate the old one).
 - Supported: add field (optionally required/unique/indexed, with backfill), change type, required/optional, unique, index, default, validation rules, select options, label; **rename a field** (column renamed, flows that use it are rewritten, including `{{ ... }}` template placeholders); deprecate / restore; **permanently delete** a deprecated field; entity label/description/status/soft-delete/audit; **drop entity**; **repair** drift (missing columns, indexes, unique constraints, NOT NULL).
-- Every change value is type-checked (`FieldChangesDto` / `EntityChangesDto`): `nullable: "false"`, `null` for a flag, an unknown field type or a too long label is a 400 `entity_builder.schema.invalid.change.value`. `update_field` can set `relationTargetEntityId` (RELATION fields only; the target must exist and is locked for the change; converting to RELATION needs one, `...blocker.relation.target.required`).
+- Every change value is type-checked (`FieldChangesDto` / `EntityChangesDto`): `nullable: "false"`, `null` for a flag, an unknown field type or a too long label is a 400 `entity_builder.schema.invalid.change.value`. `update_field` can set `relationTargetEntityId` (RELATION fields only; the target must exist and is locked for the change; converting to RELATION needs one, `...blocker.relation.target.required`). `add_field` and `create-entity` hold new fields to the same rules: a RELATION field needs an existing target (`...blocker.relation.target.required`), a target on any other field type is not stored, and a default value the field would refuse is a blocker (`...blocker.default.invalid`).
 - **Optimistic concurrency**: send `expectedUpdatedAt` (the `updatedAt` you loaded - of the field for field actions, of the entity otherwise; select `updatedAt` when reading) with `plan-change` / `apply-change`; a newer one answers 409 `entity_builder.schema.stale.definition`. Every run re-reads the definitions inside its own transaction (under the entity lock when applying) and only trusts those; a field renamed or deprecated meanwhile blocks with `...blocker.definition.changed`.
 - `LONG_TEXT`, `JSON` and `MULTI_SELECT` fields cannot be unique or indexed (`entity_builder.schema.not.indexable`). Index and unique names are `idx_` / `uq_` + table + column cut to the driver limit (63 PostgreSQL, 64 MySQL) + a hash of table and column, so they never collide.
 - Dropping an entity is blocked while relation fields of other entities point at it (`...blocker.drop.relation.in.use`, listing `"entity.field"`).
@@ -47,9 +53,15 @@ Works on PostgreSQL and MySQL (via `SchemaDialectAdapterService`). Import `Entit
 - Changes made outside the entity builder (a column dropped by hand) show up in `inspect` and are fixed by `repair`; extra columns are reported and never dropped automatically.
 - The entity/field metadata `update` endpoints are gone on purpose: every edit goes through `apply-change` so the table, the metadata and the schema cache cannot disagree.
 - Identifiers must match `^[a-z][a-z0-9_]{2,59}$`, not be an SQL reserved word, and the table (`eb_<code>`) must not already exist. Every DDL change takes a per-entity lock (`pg_advisory_xact_lock` / `GET_LOCK`, names over 64 characters hashed) - plus the lock of any relation target it points at - and is written to `eb_schema_change_log`.
-- Every filter/sort key of a flow's **Find records** step and of a `lookup` is checked against the entity's real fields; unknown keys are rejected (never interpolated into SQL). A filter value is a plain value (`=`) or `{ op, value? }` with `op` one of `eq`, `ne`, `gt`, `gte`, `lt`, `lte`, `in` (a list of at most 100 scalars; an empty list matches nothing), `is_null`, `not_null`. Operators map to a fixed SQL table and every value is a bound parameter.
+- Every filter/sort key of a flow's **Find records** step and of a `lookup` is checked against the entity's real fields; unknown keys are rejected (never interpolated into SQL). A filter value is a plain value (`=`; `null` means `IS NULL`) or `{ op, value? }`. Each operator has a value kind (`FILTER_OP_VALUE_KIND`):
+  - **single** - `eq`, `ne` (`null` = is / is not null), `gt`, `gte`, `lt`, `lte`, and the case-insensitive text operators `ieq`, `contains`, `not_contains`, `starts_with`, `ends_with` (`%`, `_`, `\` in the text match literally; a blank text is refused, since it would match every record).
+  - **list** (at most 100 scalars; a single scalar counts as a one-item list) - `in` (empty: matches nothing), `not_in` (empty: matches everything), and the multi-select operators `has_any` (empty: nothing), `has_all`, `has_none` (empty: everything).
+  - **range** - `between` / `not_between` on `[from, to]`, both ends included (in a flow: `{ from, to }`, each its own expression).
+  - **none** - `is_null` / `not_null` (SQL null, any field), `is_empty` / `not_empty` (null or blank text, or null or an empty multi-select list).
+
+  Operators must fit the field (`entity_builder.generic_record.filter.operator.not.for.field` otherwise): text operators need a text, long text, email or single-select field; `has_*` a multi-select; blank checks a text or multi-select; on multi-select and JSON fields only the null and blank checks are allowed. As in SQL, a negation (`ne`, `not_in`, `not_contains`, `not_between`, `has_none`) never matches a record whose field has no value - combine with `is_null` in another filter when those are wanted. Text matching is `ILIKE` on PostgreSQL and `LIKE` on MySQL (case-insensitive under its default collation); multi-select matching is `@>` / `JSON_CONTAINS`. Every value is a bound parameter. A Find step's `sort` is `{ field, direction? }` with a column code and `ASC` / `DESC` (left out: `ASC`); anything else is a save error (`flow.validation.node.sort.invalid`).
 - **Search** (a Find records step's search text) matches every searchable field by its text form, case-insensitively on both drivers (`CAST ... AS TEXT ILIKE` / `CAST ... AS CHAR LIKE`), so non-text fields can be searchable; `%` and `_` in the search text are literal.
-- Each entity gets the IAM actions `entity_builder.entity.<code>.<create|read|update|delete>` (only when IAM is installed); flows running as the caller check them on every entity step. DECIMAL fields are returned as numbers. `RELATION`/`FILE` are plain uuid columns (`char(36)` on MySQL, which has no uuid type) with no foreign-key constraint.
+- Each entity gets the IAM actions `entity_builder.entity.<code>.<create|read|update|delete>` (only when IAM is installed). Flow steps do not check them (a flow's URL access is its gate): the entity's ready-made flow asks for them as its URLs' `permission` access, and any Request step or Check permission step can name them in its rule. DECIMAL fields are returned as numbers. `RELATION`/`FILE` are plain uuid columns (`char(36)` on MySQL, which has no uuid type) with no foreign-key constraint. Record events are `entity-builder.<code>.created` / `updated` / `deleted`, or `purged` for a delete on an entity with soft delete turned off - the same name whether the write ran inside a transactional flow or not.
 - **Tenants never share schemas**: every tenant DataSource gets its own copy of the entities array (`getEntityBuilderEntities()` returns a copy), and runtime schemas are registered per DataSource.
 - `forRootAsync` takes `useFactory`, `useClass`, `useExisting` or a static `config`; with none of them it throws at configuration time. The root entry also exports the flow types, errors and `validateFlow`, and the schema helpers (`schema-columns`, `identifier-rules`, `field-type-conversion`).
 
@@ -65,37 +77,58 @@ Conditions and expressions are declarative JSON (`RuleGroup` / `RuleExpression`)
 - **Permission functions**: `HAS_PERMISSION(code, branch?)`, `HAS_ANY_PERMISSION(codes, branch?)`, `HAS_ALL_PERMISSIONS(codes, branch?)` give a boolean for the signed-in user (`codes`: a list or comma/space separated text, at most 50; `*` / `prefix.*` grants match). Use them as a condition's `left` with `is_true` ("user has") / `is_false` ("user doesn't have"), or as a value in Set / Switch. `branch` omitted = the user's current branch, null or empty = company-wide grants only, otherwise that branch id. Company and tenant are never arguments: a flow checks in the caller's own company, and the tenant database is the request's. Codes come from `PERMISSION_RESOLVER` (nestjs-iam: cached, rebuilt from roles and direct grants for a branch not loaded yet); without IAM the shared permission cache is used (only scopes the user has loaded), and with neither the check fails with `PermissionSystemUnavailableException`. A flow fetches each branch's codes once per run. No signed-in user = false (the validator warns about permission checks in `public` / `api_key` flows).
 - **Request functions** (flows only; elsewhere `null` / false): `HEADER(name)` (any letter case; `authorization`, `cookie`, `x-api-key`, `proxy-authorization` are never visible), `QUERY_PARAM(name)`, `IP_IN_RANGE(ip, ranges)` (IPv4/IPv6 addresses and CIDR blocks, list or comma separated text, at most 100; an IPv4-mapped IPv6 caller compares as IPv4; a bad range is refused on save and fails with `rule_engine.invalid.ip.range` at run time).
 - **Text functions**: `LOWER`, `UPPER`, `TRIM`, `LENGTH` (text or list), `SPLIT_PART(text, separator, position?)` (1-based, negative counts from the end, trimmed; e.g. the first `x-forwarded-for` address), `REGEX_EXTRACT(text, pattern, group?)` (RE2; default group 1 when the pattern has one, else the whole match), `REPLACE(text, find, with)` (plain text, every occurrence), `TO_NUMBER(value)` (`null` when not numeric).
-- **Lookup** (`{ "type": "lookup", "entity", "filter", "mode": "exists" | "count" | "first", "field"?, "sort"? }`): reads another entity. `filter` maps a column to an expression (`=`) or `{ op, value? }` (the filter operators above). `exists` gives a boolean, `count` a number, `first` the first row (after `sort`) or its `field`, `null` when none. The read goes through the flow's per-entity `read` check (run-as caller) and transaction; a rule evaluated outside a flow has no reader and fails with `rule_engine.lookup.resolver.unavailable`.
+- **Lookup** (`{ "type": "lookup", "entity", "filter", "mode": "exists" | "count" | "first", "field"?, "sort"? }`): reads another entity. `filter` maps a column to an expression (`=`) or `{ op, value? }` (the filter operators above). `exists` gives a boolean, `count` a number, `first` the first row (after `sort`) or its `field`, `null` when none. The read goes through the flow's transaction, with no per-entity permission check (the URL's access is the gate); a rule evaluated outside a flow has no reader and fails with `rule_engine.lookup.resolver.unavailable`.
 
 ## Flows (virtual APIs)
 
-A flow is an endpoint (`POST /api-flows/<slug>`) whose behaviour is a graph of steps, so a backend can be built without writing backend code. Steps: **Request** (trigger), **Validate** (checks that must pass), **Check permission**, **Code** (sandboxed JavaScript), **Set variables**, **If**, **Switch**, **For each**, **Create / Update / Delete / Get / Find record**, **Save progress**, **Call flow**, **HTTP request**, **Publish event**, **Respond**. Each step's result is `context.<stepId>`; the request body is `input.*`; also `vars.*`, `loop.item` / `loop.index` (inside a loop within a loop the outer loop is `loop.parent.item` / `loop.parent.index`, and so on up), `request.*`, `user.*`. `request` holds `ip`, `method`, `path`, `query` (text values, first of a repeated one, at most 50), `headers` (lower-case names, credential headers removed; read dashed names with `HEADER()`), and ready-made `userAgent`, `origin`, `referer`, `contentType`, `language` (first `accept-language` tag) and `receivedAt`. Text can use `{{ scope.path }}` placeholders (the `template` expression). Steps connect by output ports (`out`, `true`/`false`, `each`/`done`, switch cases, `error`); a step marked "carry on if it fails" stores `context.<id>.error` and follows its `error` port. Inside a transaction (transactional flows and every dry run) such a step runs in a savepoint, so its failure does not abort the flow's transaction.
+A flow is an endpoint (`POST /api-flows/<slug>`) whose behaviour is a graph of steps, so a backend can be built without writing backend code. Steps: **Request** (trigger), **Validate** (checks that must pass), **Check permission**, **Company & Branch check**, **Code** (sandboxed JavaScript), **Set variables**, **If**, **Switch**, **For each**, **Create / Update / Delete / Get / Find record**, **Save progress**, **Call flow**, **HTTP request**, **Publish event**, **Send notification** / **Send email** (only when the app runs those modules), **Respond**. Each step's result is `context.<stepId>`; the request body is `input.*`; also `vars.*`, `loop.item` / `loop.index` (inside a loop within a loop the outer loop is `loop.parent.item` / `loop.parent.index`, and so on up), `request.*`, `user.*`. `request` holds `ip`, `method`, `path`, `query` (text values, first of a repeated one, at most 50), `headers` (lower-case names, credential headers removed; read dashed names with `HEADER()`), and ready-made `userAgent`, `origin`, `referer`, `contentType`, `language` (first `accept-language` tag) and `receivedAt`. Text can use `{{ scope.path }}` placeholders (the `template` expression). Steps connect by output ports (`out`, `true`/`false`, `each`/`done`, switch cases, `error`); a step marked "carry on if it fails" stores `context.<id>.error` and follows its `error` port. Inside a transaction (transactional flows and every dry run) such a step runs in a savepoint, so its failure does not abort the flow's transaction.
 
 - **Loops hand data on** by `collect` (evaluated after each pass, reading `loop.*` and the body steps; the values become `context.<loop>.results` next to `count` - collect a Set/Code step to hand on several values), by variables (`vars` is flow-wide and survives passes; initialize before the loop), and by body step results (after the loop they hold the last pass).
 - **Reference timing** (validation warnings): a step's result exists for the steps on a path after it; once a loop is done (`done` branch) its whole body's results exist too (their last pass). The validator warns when a step reads `context.<id>` of a step that has not run yet when it runs (later on the path, on another branch, or later in the same loop body), `loop.*` outside a loop's `each` branch (a foreach's own `collect` counts as inside), `loop.parent` beyond the loops around the step, or `context.<loop>.results` inside that loop (only `count` exists until it is done). Unreachable steps are not checked (they already warn).
 
 - **Validate**: `{ checks: [{ id, rule, message, field? }], mode: 'all' | 'first', statusCode? }`. `all` (default) evaluates every check and rejects with every failure; `first` stops at the first. The answer is `statusCode` (default 400, or 403 when every failed check is a permission check) with `errors: [{ field, message }]` (`field` defaults to the check id); one failure uses its message as the top-level message, several use `flow.checks.failed`. Example (attendance check-out): check 1 `left` = lookup `attendance` with `employee_id = input.employeeId`, `out_time is_null`, `in_time gte START_OF_DAY(NOW())`, mode `exists`, `is_true`; check 2 `left` = `DATE_DIFF(NOW(), <same lookup, mode first, field in_time>, 'hour')` `greater_or_equal` 5.
-- **Check permission** (`permission_check`): `{ codes, match: 'any' | 'all', branch?, onDenied: 'reject' | 'branch', statusCode?, message? }`. `reject` (default) answers `statusCode` (403) with `message` (or `flow.permission.denied`) and stops, otherwise follows `out`; `branch` follows `allowed` / `denied` and never rejects. `branch` left out = the caller's current branch, `null` = company-wide grants, an expression = that branch id. Output `{ allowed, missing }`. A caller who is not signed in is denied (and the validator warns in `public` / `api_key` flows).
+- **Check permission** (`permission_check`): `{ permissions, subject?, userId?, companyId?, branchId?, onDenied: 'reject' | 'branch', statusCode?, message? }` - `permissions` is an AND / OR rule of permission codes (`ILogicNode` of nestjs-shared: `{ type: 'action', actionId: <code> }` or `{ type: 'group', operator: 'AND' | 'OR', children }`, nested up to 5 group levels, at most 50 codes; evaluated by `evaluatePermissionLogic()`, `*` / `prefix.*` grants match) `reject` (default) answers `statusCode` (403) with `message` (or `flow.permission.denied`) and stops, otherwise follows `out`; `branch` follows `allowed` / `denied` and never rejects. Checks the effective permissions (the same codes `my-permissions` returns) of the signed-in caller (`subject: 'caller'`, the default) or of the user `userId` names (`subject: 'user'`, signed in or not - e.g. the approver of a record, also on a public or API-key URL). The scope is `companyId` (left out: the caller's current company) plus `branchId` (left out: the caller's current branch when checking the caller in that company, otherwise company-wide grants only; resolving to nothing: company-wide only) - with the company feature a branch adds its own grants on top of the company-wide ones; without it IAM ignores both. The caller in their current company and branch uses the run's cached codes; any other scope is first checked against what the user is granted (`COMPANY_ACCESS_RESOLVER`: the company, and the branch inside it) - a company or branch they are not granted holds no permissions - then asked of `PERMISSION_RESOLVER` (`RuleEngineService.permissionCodes`). Output `{ allowed, missing }` - `missing` lists every code the rule names that the user does not hold, whether or not the rule passed. No user (a caller who is not signed in, or a `userId` that resolves to nothing) is denied; the validator warns when a check of the caller sits behind a `public` / `api_key` URL (not one of another user), and requires `userId` for `subject: 'user'` (`node.access.user.required`).
+- **Company & Branch check** (`company_branch_check`, company feature): `{ subject?, userId?, companyIds?, branchIds?, branchMatch?, branchCompany?, onDenied?, statusCode?, message? }` - what a user may work in: the signed-in caller (`subject: 'caller'`, the default) or the user `userId` names (`subject: 'user'`, signed in or not - e.g. the owner of a record, also on a public or API-key URL). It needs no permission codes: it gets exactly what company select offers that user - the active companies granted to them and, inside those, the active branches granted to them. Output: `{ userId, currentCompanyId, currentBranchId, companies, branches }` - `companies` as `{ id, name }` (by name), `branches` as `{ id, companyId, parentId, name }` (per company, by serial); `currentCompanyId` / `currentBranchId` are the caller's current ones (null for another user). `companyIds` / `branchIds` (expressions: one id or a list, typically the record being changed; the designer starts the caller's on `user.companyId` / `user.branchId`) turn it into a guard: each id must be within reach (`allowed`, `missing: { companyIds, branchIds }`); a target that resolves to nothing is a denial. A company is within reach when it is granted; a branch per `branchMatch`: `direct` (default) - one of the granted branches; `within` - a granted branch or anywhere under one (`parentId` tree, `getDescendantIds(granted, { includeSelf: true })`, walked only when an asked-for branch is not granted itself), a child needing no grant of its own and the current branch playing no part. A user with no granted branch reaches none; without the branch tree `within` passes only granted branches. `branchCompany` picks whose branches count, for both matches (a walk starts only from the granted branches it keeps): `any` (default, stored as no key) - every company of the user; `current` - the caller's current company (refused on save for another user, who has none; no current company counts none). Then `onDenied` rejects (default, `statusCode` 403) or follows `allowed` / `denied` (which needs a target). No user means nothing is reachable. The data comes from `COMPANY_ACCESS_RESOLVER` and the tree from `BRANCH_HIERARCHY_RESOLVER` (nestjs-shared), both provided by nestjs-auth when the company feature is on (the grants `UserPermissionService` lists, kept to active companies and branches, looked up once per user per run); without them nothing is reachable. Save warns about a check of the caller on a URL reached without signing in (`permission.without.user`), not about one of another user. The designer offers the step only with the company feature.
 - **Code**: `{ code, timeoutMs? }` runs `code` as the body of a synchronous function in a QuickJS WebAssembly sandbox (`quickjs-emscripten`) on a worker thread (a small pool, at most 4), so a busy code step never blocks the server's event loop; the host also kills a worker that overruns its deadline. It reads a deep-frozen JSON copy of `{ input, vars, context, loop, user: { id, email, name, companyId, branchId, permissions? } }` as the global `ctx` (no request headers; `permissions`, the caller's codes in the current branch, is fetched only when the code mentions permissions). `hasPermission(code)`, `hasAnyPermission(...codes)` and `hasAllPermissions(...codes)` are plain JavaScript inside the sandbox over `ctx.user.permissions` with the server's wildcards and `return`s a JSON value, which becomes `context.<id>`. Nothing of the host is reachable (no `require`, `process`, network, filesystem, timers or database); `console.log` is captured into the trace (`trace[].logs`, 50 lines of 500 characters, sensitive-looking keys masked). Every run gets a fresh runtime with a 32 MB memory limit, a 512 KB stack and an interrupt deadline of `timeoutMs` (default 1000, 10-5000) clamped to the time left in the flow; the output may be at most 1 MB. A throw, time-out or memory overflow is a node error (`flow.error.code.*`), so `onError: continue` and the `error` port work. Code nodes also run in dry runs. Saving a flow that contains a code node needs `entity_builder.flow_definition.code`.
 - **Create / Update / Delete record** write several records in one step through `target`: `one` (default, left out) writes one record; `many` writes one per item of `items` (up to `FLOW_LIMITS.MAX_WRITE_ITEMS` = 1000), and the step's per-record values (`fields`, `id`) read the item as `loop.item` / `loop.index` with a loop around the step as `loop.parent`; `filter` (update / delete) writes every record matching `filter` (same shape as Find), read as `loop.item` (e.g. `stock = loop.item.stock - 1`). A filter that resolves to nothing is refused (`flow.error.write.filter.empty`) instead of changing every record, and more matches than `limit` (1-1000, default 100) fail the step (`flow.error.too.many.matches`) instead of changing some. In `many` mode `id` defaults to the item's own id (the item itself when it is text, else `item.id`). `onNotFound`: `error` (default), `skip`, or for update `insert` (upsert: a missing record, or in `many` mode an item with an empty id, is created with the same field values - needs the entity's `create` permission too). Create takes `children` (up to 10): `{ as, entityCode, parentField, items, fields }` saves child records under every saved record, `parentField` filled with the parent's id; `items` is read in the parent's scope (`loop.item.lines` in `many` mode, `input.lines` otherwise) and child `fields` read the child item as `loop.item` and the parent's scope as `loop.parent`. Results: create one = the record plus one array per `as`; create many = `{ items, count }`; update one = the record (`null` when skipped); update many / filter = `{ items, count, updated, created, skipped }`; delete one = `{ id, deleted }`; delete many / filter = `{ ids, count, skipped }` (an id listed twice is deleted once). A create never takes an `id` field (`generic_record.system.column.readonly`), so it cannot overwrite an existing record; an upsert's created record ignores a mapped `id`. A step that writes several records (`many`, `filter`, or any `children`) is **all-or-nothing on its own**: inside a transactional run it uses the run's transaction, otherwise it opens a transaction for just that step and publishes its record events after that commit. Every record written counts against `FLOW_LIMITS.MAX_WRITES_PER_RUN` (5000, shared with called flows).
-- **Save progress** (`commit`, no settings, port `out`): commits everything the run has written so far, publishes the events held back until then, and starts a new transaction for the rest (the statement timeout is set again). A later failure rolls back only what came after it; the run's result then carries `savedUpTo: { nodeId, name, at }` (the last one that committed) and a failed answer's body `savedUpTo: '<step name>'`, so a caller knows the first part is already saved (make a retry check for it). It commits only in the transaction the run opened itself - it is skipped (trace `skipped`, `reasonKey` `flow.skip.commit.*`) in a test run (nothing is ever saved there), in a flow without the transaction setting (every step already saves on its own) and in a flow called inside its caller's transaction (only the caller may commit that one; a called flow that opened its own transaction commits normally). It cannot be set to carry on if it fails (a save error). Save-time warnings: a Save progress step in a flow without the transaction setting, inside a loop (it saves once per item - fine for batch imports) or in a flow other flows call; and, for any flow, two or more write steps without the transaction setting.
-- **Call flow** (`call_flow`): `{ flowSlug, input }` runs another active flow as part of this run and puts its answer in `context.<id>`: its `respond` body, or the output of its last step. The called flow gets `input` checked against its own input schema (a mismatch rejects with 400), the same caller, request and test mode, and shares the run's step, HTTP-call and time budget. It joins the caller's transaction when there is one (so a dry run rolls back its writes too, and its events wait for the caller's commit; a joined call that fails or answers 4xx/5xx drops the events it queued, so a caller that continues past it with `onError: continue` never announces writes the savepoint rolled back); otherwise a transactional called flow commits on its own. A called flow that answers 4xx/5xx, or rejects (validate, permission), passes that answer on as the caller's; any other failure fails the step with `flow.error.called.flow.failed[.at.node]`, so `onError: continue` and the `error` port work. Access: any flow may call a function (`internal`), which then runs as its caller's run does (`runAs` inherited, its own ignored); a flow running as the system may call any flow; one running as the caller may call only what that caller could call directly - `public` and `jwt` flows, and `permission` flows when the caller holds the permission, never an `api_key` flow. A chain that comes back to a running flow and nesting deeper than 5 levels stop the run. On save the step must name an existing flow the author can see (not the flow itself), and what the runtime would always refuse is refused then too: an `api_key` flow from a flow running as the caller (only a warning from a function, which runs as whoever calls it), a required input (without a default) left unmapped, a chain of calls that comes back to this flow, and a chain nested deeper than `FLOW_LIMITS.MAX_CALL_DEPTH`. Calling an inactive flow, and mapping an input the called flow does not declare (it is dropped), are warnings; a flow another flow calls cannot be deleted or have its URL name changed until those callers are changed.
-- **Several URLs in one flow**: a flow can hold more than one **Request** step. The one without a `path` answers on `POST /api-flows/<slug>` and takes the flow's `bodyType` / `inputSchema`; each other one sets `config.path` (1-63 lowercase letters, digits and dashes, starting with a letter; `ITriggerConfig`) and answers on `POST /api-flows/<slug>/<path>` with its own `config.bodyType` / `config.inputSchema` - e.g. a `customer-ticker` flow with `insert` (an object) and `insert-many` (a list) sharing the steps after them. Saving needs at least one Request step (`trigger.missing`), at most one without a path (`trigger.main.duplicate`) and distinct, valid paths (`trigger.path.duplicate` / `.invalid`); a path's fields are checked like the flow's, with errors named `<path>: <field>`. A flow whose every Request step has a path answers 404 on its own URL. Auth mode, permission, rate limit, run-as, transaction and timeout stay per flow. `flowEndpoints()` / `findEndpoint()` (`flow.types.ts`) turn the Request steps into `IFlowEndpoint`s; the run starts at `IFlowRunState.startAt`. The test run takes `endpoint` (a path; left out, the flow's own URL - an unknown one is refused with `flow.endpoint.not.found`), and a Call flow step takes `config.endpoint` to start the called flow at one of its paths, checked on save against that path's body (`node.flow.endpoint.unknown`, or `.required` when the called flow has no own URL) and at run time (`error.called.flow.endpoint.not.found`).
-- **Body type** (`bodyType`, column `body_type`, default `object`): `object` - the body is one object and the input fields are its keys (`input.<name>`); `list` - the body itself is a list, like `insert-many` (`POST api-flows/<slug>` with `[{...}, {...}]`), the input fields describe each item, every item is checked the same way (errors name the index: `[0].sku`; a body that is not a list is refused with `flow.input.body.not.list`), and the flow reads the list as `input` (a For each over `input`, or `input.0.<name>`). With no fields declared a list body is passed through as-is. A Call flow step sends a list-bodied flow one expression, `inputList`, instead of named `input`s; saving checks the step matches the called flow's body type (`node.flow.input.list.required` / `.unexpected`). The test run accepts a list `input` too.
-- **Input**: the flow declares the request fields (type, required, default, min/max, choices). The body is checked and converted with the same validator entity records use; undeclared keys are dropped; every problem is returned at once (400). An `object` field may declare its own `fields`; an `array` field may declare an `itemType` (any type but `array`) that every item must have - min/max/length/options then apply to each item - and a list of objects (`itemType: 'object'`) declares the `fields` of each item. Nested values are checked the same way (undeclared keys inside them are dropped too), errors name their path (`address.city`, `items[0].qty`), and nesting goes at most `FLOW_LIMITS.MAX_INPUT_DEPTH` (4) levels. Without `fields` / `itemType` the value is only checked to be an object / a list. Generated entity flows declare `ids` as a list of ids; their bulk flows use a `list` body whose items are the entity fields.
-- **Who can call it**: `public`, `api_key` (`x-api-key`, only a SHA-256 hash stored, constant-time compare; a key past its `expiresAt` answers 401 `flow.api.key.expired`; keys are only checked while the auth mode is `api_key`, so they stop working when it changes), `jwt` (any signed-in user), `permission` (`entity_builder.flow.<slug>.execute` by default, provisioned as an IAM action) or `internal` - a **function**: no endpoint of its own, run only by other flows' Call flow steps, for logic several flows repeat. Unknown, inactive and `internal` flows all answer 404 on `POST /api-flows/<slug>`. A per-caller-IP rate limit runs **before** credentials are checked (in memory per server instance, fixed one-minute windows, at most 10,000 tracked callers - the oldest window is dropped beyond that).
-- **Find record** filters accept the `{ op, value }` operators (the value side is an expression). A filter entry is an operator only when it is authored as exactly `{ op, value? }` with a known `op` (any other key, or an unknown `op`, and it is not a condition - so an expression such as `{ type: 'arithmetic', op: 'add', ... }` is a plain value). A value resolved at run time (from input, a variable, a step result) is only ever an operand: an object or list is compared for equality and refused as not one value, never read as an operator, so `{ "op": "not_null" }` sent as input cannot widen a Find, lookup, update or delete. On a Find an entry that resolves to nothing is left out; on an update / delete by filter it fails the step (`flow.error.filter.value.missing`) instead of widening the write.
+- **Send notification** (`send_notification`) and **Send email** (`send_email`) send through the notification and email modules, reached only through the `NOTIFICATION_ADAPTER` / `EMAIL_ADAPTER` tokens of `nestjs-shared` (`@Optional()`, so the package never imports either module). **Who gets it** (`target`): `one` (default, stored as no key) sends one message; `many` sends one per item of `items` (at most `MAX_MESSAGES_PER_RUN`), every other value read with the item as `loop.item` (the validator scopes `loop.*` for the step itself), an item with nobody to send to is skipped, and **every item is checked before the first message goes out** (the run's message budget is taken for all of them first, so a limit never leaves a batch half sent); a notification's `company` target notifies every active member (active grant, active and not deleted user) of `companyIds` (one or a list; with `branchIds`, only members also in one of those branches) through `COMPANY_ACCESS_RESOLVER.getCompanyMembers` (implemented by `nestjs-auth` on its existing company/branch reverse lookups), one notification per company shown under that company, at most `MAX_COMPANY_NOTIFICATION_RECIPIENTS` (5000) in all. The `company` target needs the company feature (refused on save without it: `validation.node.notification.company.unavailable`; at run time `error.notification.company.unavailable`), and it may notify any company the author names - as with entities, the URL's access is the gate. Outputs: many / company add `count` (messages) and, for a list, `skipped`; an email list hands on `messageIds` (one per email sent, in order). A step whose module the app does not run is refused on save (`validation.node.notification.unavailable` / `.email.unavailable`, checked by `FlowDefinitionService.validate`) and fails at run time (`error.notification.unavailable` / `.email.unavailable`). Notification: `{ userIds, title, message?, type?: info|success|warning|error, data?, companyId?, realtime? }` - `userIds` is one user id or a list (each once; anything but a UUID rejects with 400), `title` is cut to 255 characters (empty rejects), `companyId` defaults to the caller's current company (it decides where the notification shows with the company feature), `realtime` (default true) pushes to online users; one `sendToMany` call. Email: `{ to, cc?, bcc?, replyTo?, mode?: content|template, subject, body, format?: text|html, templateSlug, variables?, emailConfigId? }` - addresses are one, a list or comma / semicolon separated text, checked, each sent once (an address already on `to` is dropped from `cc` / `bcc`), at most `MAX_EMAIL_RECIPIENTS` (50) in all, `replyTo` a single one; `content` needs `subject` (line breaks removed, cut to 255) and `body`; with `format: html` the values a `template` expression fills in are HTML-escaped (`RuleEngineService.resolveHtml`), any other expression is sent as the HTML it holds; `template` needs `templateSlug` and fills it with `variables` (escaped by the email module); `emailConfigId` defaults to the company's default configuration. A provider that answers `success: false` or throws fails the step (`error.email.failed` / `error.notification.failed`, with the reason), so `onError: continue` and the `error` port work. Nobody to send to (empty `userIds` / `to`) skips the step (`skip.no.recipients`). Output: `{ status: 'sent' | 'queued', recipients }` (+ `messageId`, null while queued). Inside a transaction the message is **queued** and sent after the commit (with the entity and flow events, in order; dropped with them when the run, a savepoint or a joined call rolls back); a send that fails then is logged, not the run's failure - the validator warns (`message.after.commit`) on such a step marked to carry on. A test run checks everything (recipients, addresses, title, subject) and sends nothing (`skip.notification` / `skip.email`). At most `MAX_MESSAGES_PER_RUN` (100) sends per run, shared with called flows, and `MAX_NOTIFICATION_RECIPIENTS` (500) per notification. A `public` Request step in a flow with such a step is flagged (`public.message`): make sure a caller cannot choose the recipients.
+- **Save progress** (`commit`, no settings, port `out`): commits everything the run has written so far, publishes the events held back until then, and starts a new transaction for the rest (the statement timeout is set again). A later failure rolls back only what came after it; the run's result then carries `savedUpTo: { nodeId, name, at }` (the last one that committed) and a failed answer's body `savedUpTo: '<step name>'`, so a caller knows the first part is already saved (make a retry check for it). It commits only in the transaction the run opened itself - it is skipped (trace `skipped`, `reasonKey` `flow.skip.commit.*`) in a test run (nothing is ever saved there), in a run whose Request step has no transaction setting (every step already saves on its own) and in a flow called inside its caller's transaction (only the caller may commit that one; a called flow that opened its own transaction commits normally). It cannot be set to carry on if it fails (a save error). Save-time warnings: a Save progress step reached from a Request step without the transaction setting (`commit.not.transactional`, naming both), inside a loop (it saves once per item - fine for batch imports) or in a flow other flows call; and two or more write steps reached from a Request step without the transaction setting (`writes.not.transactional`, naming that Request step).
+- **Call flow** (`call_flow`): `{ flowSlug, endpoint?, input }` runs another active, published flow from one of its Request steps (`endpoint` = that step's path; left out, its own URL) - never from a step in the middle, since only a Request step declares what input it takes - as part of this run and puts its answer in `context.<id>`: its `respond` body, or the output of its last step. The called flow gets `input` checked against its own input schema (a mismatch rejects with 400), the same caller, request and test mode, and shares the run's step, HTTP-call and time budget. It joins the caller's transaction when there is one (so a dry run rolls back its writes too, and its events wait for the caller's commit; a joined call that fails or answers 4xx/5xx drops the events it queued, so a caller that continues past it with `onError: continue` never announces writes the savepoint rolled back); otherwise a called flow whose Request step is transactional commits on its own. A called flow that answers 4xx/5xx, or rejects (validate, permission), passes that answer on as the caller's; any other failure fails the step with `flow.error.called.flow.failed[.at.node]`, so `onError: continue` and the `error` port work. Access (of the Request step it starts at, checked against the run's user): any flow may start at an `internal` step or a `public` URL; a `jwt` URL needs a signed-in user, a `permission` one the user holding the permission; an `api_key` URL is never callable from a flow, which has no key to send. A chain that comes back to a running flow and nesting deeper than 5 levels stop the run. On save the step must name an existing flow the author can see (not the flow itself), and what the runtime would always refuse is refused then too: an `api_key` URL, a required input (without a default) left unmapped, a chain of calls that comes back to this flow, and a chain nested deeper than `FLOW_LIMITS.MAX_CALL_DEPTH`. Calling an inactive flow, and mapping an input the called flow does not declare (it is dropped), are warnings; a flow another flow calls cannot be deleted or have its URL name changed until those callers are changed. Publishing a flow (or saving a never-published one, which changes in place) also re-checks every active, published flow that calls it, directly or through other flows, against the flows as the change leaves them, and refuses the change (409, `entity_builder.flow.callers.broken`, with each broken caller's problems in `errors`) when it adds a problem the caller did not already have: a removed or renamed path, a step switched to `api_key`, a new required input, a body switched between object and list, the flow switched off, or a chain that now loops or nests too deep. Permission steps are judged per user at run time only.
+- **Several URLs in one flow**: a flow can hold more than one **Request** step, and each one carries everything about its URL and its runs in its `config` (`ITriggerConfig`): `path`, body (`bodyType`, `inputSchema`), access (`authMode`, `permissions`, and `apiKey` for API-key access), `isTransactional`, `timeoutMs` and `rateLimitPerMinute` - each left out at its default. The flow itself has none of these: it only groups its URLs under one slug, switches them on and off together (`isActive`), keeps their run history (`retainExecutions`) and is versioned as a whole. The one without a `path` answers on `POST /api-flows/<slug>`; each other one sets `config.path` (1-63 lowercase letters, digits and dashes, starting with a letter) and answers on `POST /api-flows/<slug>/<path>` - e.g. a `customer-ticker` flow with `insert` (an object) and `insert-many` (a list) sharing the steps after them. Saving needs at least one Request step (`trigger.missing`), at most one without a path (`trigger.main.duplicate`) and distinct, valid paths (`trigger.path.duplicate` / `.invalid`); every Request step's fields are checked the same way (errors on a path's fields are named `<path>: <field>`). A flow whose every Request step has a path answers 404 on its own URL. `flowEndpoints()` / `findEndpoint()` / `startEndpoint()` (`flow.types.ts`) turn the Request steps into `IFlowEndpoint`s with every setting's default filled in; the run starts at `IFlowRunState.startAt` and takes that step's transaction and time limit. Save checks each step's settings (`trigger.transaction.invalid`, `trigger.timeout.range` 1-120 s, `trigger.rate.limit.range` 0-100,000), and every warning that depends on them - record steps open without sign-in (`keyless.entity`), transactions, HTTP inside a transaction - looks only at the steps that Request step's runs reach. The test run takes `endpoint` (a path; left out, the flow's own URL - an unknown one is refused with `flow.endpoint.not.found`), and a Call flow step takes `config.endpoint` to start the called flow at one of its paths, checked on save against that path's body (`node.flow.endpoint.unknown`, or `.required` when the called flow has no own URL) and at run time (`error.called.flow.endpoint.not.found`).
+- **Body type** (a Request step's `config.bodyType`, default `object`, left out when `object`): `object` - the body is one object and the input fields are its keys (`input.<name>`); `list` - the body itself is a list, like `insert-many` (`POST api-flows/<slug>` with `[{...}, {...}]`), the input fields describe each item, every item is checked the same way (errors name the index: `[0].sku`; a body that is not a list is refused with `flow.input.body.not.list`), and the flow reads the list as `input` (a For each over `input`, or `input.0.<name>`). With no fields declared a list body is passed through as-is. A Call flow step sends a list-bodied flow one expression, `inputList`, instead of named `input`s; saving checks the step matches the called flow's body type (`node.flow.input.list.required` / `.unexpected`). The test run accepts a list `input` too.
+- **Input**: each Request step declares its request fields (`config.inputSchema`) (type, required, default, min/max, choices). The body is checked and converted with the same validator entity records use; undeclared keys are dropped; every problem is returned at once (400). An `object` field may declare its own `fields`; an `array` field may declare an `itemType` (any type but `array`) that every item must have - min/max/length/options then apply to each item - and a list of objects (`itemType: 'object'`) declares the `fields` of each item. Nested values are checked the same way (undeclared keys inside them are dropped too), errors name their path (`address.city`, `items[0].qty`), and nesting goes at most `FLOW_LIMITS.MAX_INPUT_DEPTH` (4) levels. Without `fields` / `itemType` the value is only checked to be an object / a list. Generated entity flows declare `ids` as a list of ids and a multi-select field as a list of its choices; their bulk flows use a `list` body whose items are the entity fields.
+- **Who can call it**: set on each Request step - there is no flow-level access. `config.authMode`: `jwt` (any signed-in user; the default, stored as no setting), `permission` (`config.permissions`: an AND / OR rule of permission codes (`ILogicNode` of nestjs-shared: `{ type: 'action', actionId: <code> }` or `{ type: 'group', operator: 'AND' | 'OR', children }`, nested up to 5 group levels, at most 50 codes; evaluated by `evaluatePermissionLogic()`, `*` / `prefix.*` grants match); none: `entity_builder.flow.<slug>.execute`, provisioned as an IAM action on publish - a rule names existing actions, which are not re-registered. The guard checks it with `SharedPermissionCacheService.assertPermissionLogic`), `api_key` (the step's own key, sent as `x-api-key`: the designer makes it (`fk_<8 hex>_<32 hex>`) and sends it in `config.apiKey` once; every save replaces it with `{ prefix, hash }` (SHA-256, `sealApiKeys()`), so the key itself is never stored and cannot be shown again. The guard compares in constant time against the published step's hash; a wrong or missing key answers 401 `flow.api.key.invalid`, and one step's key never opens another. A step without a key cannot be saved (`trigger.api.key.required`, or `.invalid` for a malformed one); a new key replaces the old one once the flow is published; a step that leaves API-key access drops its key), `public`, or `internal` - **other flows only**: the step has no URL (it answers 404), only other flows' Call flow steps start there, and that run takes the calling flow's user. A flow whose every Request step is `internal` is a **function** (`isFunctionFlow()`). A URL reached without signing in (`public`, `api_key`) runs with no `user`: permission checks and the caller's Company & Branch check deny, while its record steps run for anyone who can call it (validator warning `keyless.entity`, naming the URLs and the entities they read or change). Unknown, inactive and never-published flows all answer 404. Each Request step's per-caller-IP rate limit (`config.rateLimitPerMinute`, default 60, 0 = unlimited; counted per step) runs **before** credentials are checked (in memory per server instance, fixed one-minute windows, at most 10,000 tracked callers - the oldest window is dropped beyond that).
+- **Find record** filters accept the `{ op, value }` operators (the value side is an expression). A filter entry is an operator only when it is authored as exactly `{ op, value? }` with a known `op` (any other key, or an unknown `op`, and it is not a condition - so an expression such as `{ type: 'arithmetic', op: 'add', ... }` is a plain value). A value resolved at run time (from input, a variable, a step result) is only ever an operand: an object or list is compared for equality and refused as not one value, never read as an operator, so `{ "op": "not_null" }` sent as input cannot widen a Find, lookup, update or delete. On a Find an entry that resolves to nothing (for a range: either bound) is left out; on an update / delete by filter it fails the step (`flow.error.filter.value.missing`) instead of widening the write. A range's value must be `{ from, to }` (`flow.shape.filter.range.invalid`). Flows and lookups resolve every entry through `resolveFilterEntry()` (`rule-values.ts`).
 - **Checks cannot be carried past**: a failed Validate or Check permission step (like Save progress) always ends the run, whatever its `onError` says.
-- **Runs as**: `caller` (every entity step and lookup re-checks `dynamicEntityPermission(entity, action)` = `entity_builder.entity.<entity>.<action>` for the caller) or `system` (no checks - so saving such a flow needs `entity_builder.flow_definition.system`, and a public system flow is flagged in the warnings). It fails closed: any other value is refused on save and at run time, and a system run touches entities only when it was granted the system (a saved flow, or a test run whose tester holds `flow_definition.system`) - otherwise every entity step and lookup answers 403 `flow.error.run.as.not.allowed`.
-- **Transactions**: a transactional flow's entity writes commit or roll back together; entity events and **Publish event** steps are published only after the commit, in order, and never for a run that rolled back - nor for the rows of a step whose savepoint (`onError: continue`) rolled back. Metadata a transactional run needs (entity and field definitions, called flows) is read on the run's own transaction, so a run never waits on a second pooled connection. HTTP calls cannot be rolled back, so a transactional flow with an HTTP step is flagged in the warnings. In a non-transactional flow each step commits on its own, except that a multi-record write step is always all-or-nothing (see above); make the flow transactional when several steps must succeed or fail together, and add **Save progress** steps where the work so far must be kept even if a later step fails.
-- **Test runs** need what running the flow for real would, for a saved flow as much as a draft and in both modes: `flow_definition.system` for run-as system, `flow_definition.code` for a code node. A `live` test run also needs what makes it real: for a draft the permission to save it (`flow_definition.create`, or `update` when it has a `flowId`), for a `permission` flow its own execute permission. The draft is validated like a saved flow (DTO: run-as, auth mode, time-out, rate limit and retention bounds; then `validateFlow`); the server-owned fields of a loaded flow (`id`, `version`, timestamps) are ignored. Test runs of unsaved drafts are logged without a flow id and pruned together, keeping the newest 200.
-- **Test runs**: `dry_run` (default) executes inside a transaction that is always rolled back and skips HTTP and events; `live` does everything. Test runs return the real error text; live callers get a safe summary. `request: { headers?, query?, ip? }` simulates what a caller would send, on top of the designer's own request, so header / query / IP rules can be tried (credential headers are still removed).
-- **Safety limits**: at most 100 nodes, 5000 steps per run (room for a full 1000-item loop with a few steps per item, and for the scaffolded 200-item bulk flows), 1000 items per loop, 10 HTTP calls, 120 s total; loops cannot nest deeper than 3; a flow cannot loop back on itself (use For each). Steps are data walked by a fixed engine; the only author-written code that runs is a code node's, inside the QuickJS sandbox described above.
+- **Access is the gate**: a Request step's *Who can call it* decides who may start a run, and then every step reads and writes records with no per-entity permission check (`entity_builder.entity.<entity>.<action>` counts only where an access rule or a Check permission step names it, as the ready-made entity flow does) and may notify any company. Finer rules are the flow's own: a **Check permission** step, a **Company & Branch check**, or `HAS_PERMISSION()` in a condition. Since whoever may save flows decides what each URL exposes, grant `flow_definition.create` / `.update` like deploy rights.
+- **Transactions** (a Request step's `config.isTransactional`, the designer's "All writes together"): the entity writes of a run that starts at a transactional Request step commit or roll back together; the flow's other URLs open no transaction unless they set it too; entity events and **Publish event** steps are published only after the commit, in order, and never for a run that rolled back - nor for the rows of a step whose savepoint (`onError: continue`) rolled back. Metadata a transactional run needs (entity and field definitions, called flows) is read on the run's own transaction, so a run never waits on a second pooled connection. HTTP calls cannot be rolled back, so a transactional Request step whose runs reach an HTTP step is flagged in the warnings. In a run without a transaction each step commits on its own, except that a multi-record write step (many, or with child records) is always all-or-nothing (see above); make the Request step transactional when several steps must succeed or fail together, and add **Save progress** steps where the work so far must be kept even if a later step fails.
+- **Test runs** need what running the flow for real would, for a saved flow as much as a draft and in both modes: `flow_definition.code` for a code node. A `live` test run also needs what makes it real: for a draft the permission to save it (`flow_definition.create`, or `update` when it has a `flowId`), for a `permission` Request step its execute permission. The draft is validated like a saved flow (DTO: retention bounds and no unknown flow setting; then `validateFlow`, which checks every Request step's access, transaction and limits); the server-owned fields of a loaded flow (`id`, `version`, timestamps) are ignored. Test runs of unsaved drafts are logged without a flow id and pruned together, keeping the newest 200.
+- **Test runs**: `dry_run` (default) executes inside a transaction that is always rolled back and skips HTTP, events, notifications and emails; `live` does everything. Test runs return the real error text; live callers get a safe summary. `request: { headers?, query?, ip? }` simulates what a caller would send, on top of the designer's own request, so header / query / IP rules can be tried (credential headers are still removed).
+- **Safety limits**: at most 100 nodes, 5000 steps per run (room for a full 1000-item loop with a few steps per item), 1000 items per loop, 10 HTTP calls, 100 notifications and emails, 120 s total; loops cannot nest deeper than 3; a flow cannot loop back on itself (use For each). Steps are data walked by a fixed engine; the only author-written code that runs is a code node's, inside the QuickJS sandbox described above.
+- **Forwarding the caller's token**: an HTTP step with `forwardAuth: true` sends the signed-in caller's own `Authorization` header (unless its `headers` set one), so the next API sees the same user. The token lives only in the run state (`IFlowRunState.authorization`, passed on to called flows) - never in `request.headers`, expressions, code steps, traces or logs - and exists only when the caller was verified (signed-in URLs; a test run forwards the tester's own). The validator warns on every such step, since the token goes to that URL.
 - **HTTP steps** never follow redirects, cap the response at 1 MB, and refuse loopback / private / link-local (cloud metadata) addresses **at connect time** (DNS-rebinding safe), including every IPv6 form that embeds or tunnels to one (IPv4-mapped `::ffff:`, IPv4-translated `::ffff:0:`, IPv4-compatible, NAT64 `64:ff9b::/96` and all of the local-use `64:ff9b:1::/48`, 6to4 `2002:`, and all of Teredo `2001::/32`). The timeout is one deadline for the whole request, response body included. For local development only, set `flows.allowPrivateHttp` in the module config or `ENTITY_BUILDER_FLOW_ALLOW_PRIVATE_HTTP=true`.
-- **Runs are logged** (`eb_flow_execution`) with the redacted input, a trace of every step and the output; the newest N (default 200) are kept.
+- **Runs are logged** (`eb_flow_execution`) with the redacted input, a trace of every step, the output and `flowVersion` (the published version that ran; null for a test run of the designer's draft); the newest N (default 200) are kept. Dates in logged values are written as ISO text.
+- **Versions**: the flow's columns are the published flow - what callers run. A new flow is created unpublished (`version` 0: callers get 404, Call flow steps refuse it, the validator treats it as inactive) and is edited in place until its first **publish** - so saving it is checked like a publish against other flows calling a URL name or path it drops. After that, saving (`update`) keeps the edits in `draft` (dropped again when they match what is live) and callers keep running the published columns. `publish` validates the draft like a save, plus what only going live can break (other flows calling a URL name or path it drops), copies it over the columns as `version + 1`, clears the draft and records the version in `eb_flow_version` (`FlowVersion`: the full snapshot, `note`, `publishedAt`, `publishedById`) `restore-version` copies any version into the draft (it needs the permissions its code steps call for, but is not validated, since the entities it names may have changed); `discard-draft` drops the draft. Everything but the flow's id is versioned (`FLOW_VERSIONED_FIELDS`), `isActive` included. Entity schema changes rewrite field references in the published flow, its draft, its kept versions and in deleted flows (so a restored version or flow keeps working), without a new version.
 - **Schema changes are flow-aware**: renaming an entity field rewrites the flows that use it; dropping an entity or field lists (and for a drop, blocks on) the flows that use it. Tracked: the entity step's `fields` / `filter` / `sort`, a create step's `children[]` (`entityCode`, `fields` keys, `parentField`), lookups, and output paths holding records - `context.<id>.<field>` (get / create / update one), `context.<id>.items.<n>.<field>` (Find, many / filter writes), `context.<id>[.items.<n>].<as>.<n>.<field>` (saved children). References reached through a loop over query results (`loop.item.<field>`) are not tracked.
 - Secrets typed into an HTTP header are stored in the flow definition (there is no credential vault yet); flows are readable only with `flow_definition.read`.
 
+## Promoting between environments
+
+Entities and flows are data, so TypeORM migrations never see them. They move from dev to staging to production as a **bundle**: a JSON file kept in git, applied to each environment through the same services the designer uses (`DefinitionBundleService`).
+
+- **Export** (`bundles/export`, or `npm run entity-bundle -- export <file>` in `FLUSYS_NEST`) writes every entity that has a table and every **published** flow (a `DRAFT` entity and an unpublished flow are left out with a warning). Entities are keyed by `code` and fields by their `id` and `code`; a relation names its target by **entity code**, never by id. Entities, fields and flows are listed in code-point order, object keys are sorted at every level (PostgreSQL and MySQL return JSON keys in different orders), and there are no timestamps. The same definitions always give the same file and checksum, and a PR diff shows exactly what changes. Each Request step's API key is left out, and every occurrence of this environment's variable values in a flow becomes `${var:NAME}`.
+- **Plan** (`bundles/plan-import`) compares the bundle with this environment. Entities and fields are matched by id first, then by code among those no id claimed (`matchDefinitions`). An import keeps the ids definitions were designed with when they are free, so a field renamed in dev arrives as a **rename** (`update_field` with `code`, which rewrites the flows that use it), not as a new field. Steps run in this order: entities switched back on, new entities (their relation fields wait until every new entity exists), restore / rename / update / add / deprecate fields of existing entities (renames ordered so none takes a code another field still has, see **Renames**), the new entities' relation fields, entities switched off, then flows with called flows before their callers. Each step that can be previewed on its own carries the real `plan-change` / `plan-create-entity` result: SQL, data checks, blockers. Only a step that runs on something an earlier step creates, restores or frees (a new entity, a relation to one, a change to a restored field, a rename or new field taking a code a rename frees) goes without a preview, and it says so. A flow is compared with its **published** version (API keys ignored). It is validated here when nothing it depends on changes in the same import, and it is always checked against the importer's own permissions: code steps need `flow_definition.code`, exactly as for a save. `mayLoseData` is `destructive` (a previewed step loses data) or a structural change that could not be previewed (type, required, unique, soft delete, audit). `checksum` is the bundle's; `planChecksum` covers the bundle, the options and every step (kind, subject, changes, whether its preview loses data), not the SQL or row counts. A `DRAFT` entity (no table) in the bundle or in this environment blocks the import.
+- **Apply** (`bundles/apply-import`) refuses a bundle whose checksum is not `expectedChecksum` (409 `entity_builder.bundle.checksum.mismatch`: not the bundle that was reviewed). It then re-plans and refuses a plan that is not `expectedPlanChecksum` (409 `entity_builder.bundle.plan.changed`: the environment changed since the review), when anything is blocked (409, every reason in `errors` as `{ field: <subject>, messageKey, messageVariables }`, since `errors` is what the global exception filter passes on), or when `mayLoseData` and no `confirm: true` (400, the steps in `errors`) or no `expectedPlanChecksum` (400 `entity_builder.bundle.plan.checksum.required`: a confirmation covers the reviewed steps only, never ones the environment grew since). `confirm` is passed on to every step. Entity steps go through `SchemaSyncService.createEntity` / `SchemaEvolutionService.apply`, so each is one locked, logged transaction. Flow steps are saved through `FlowDefinitionService` (validated, permission-checked) and **published** as a new version with the note `Imported from bundle <checksum>`. The import is not one transaction (MySQL commits DDL at once): the first step that fails stops it (`completed: false`, its `error` and `blockers`), the earlier ones stay, and the later ones are `skipped`. Importing the same bundle again picks up where it stopped, because every step compares before it changes.
+- **Never removes anything.** Entities, fields and flows this environment has and the bundle does not are listed as `extras`. With `deprecateMissingFields` the missing fields are deprecated, which keeps their columns and data. Dropping stays a deliberate `apply-destructive-change`. An entity whose code changed (same id, different code) blocks the import, because an entity code cannot be renamed.
+- **API keys**: a Request step with API-key access keeps the key this environment already stores for that step (matched by node id). Otherwise a new key is generated, returned **once** in `apiKeys`, and only its hash is stored. A key is answered as soon as its flow is saved, so it is not lost when publishing fails afterwards (the next import keeps it).
+- **Ids**: a design-time id is reused only when no row has it, soft-deleted rows included.
+- **Renames**: renames run in an order that never takes a code another field still has. A rename waits for the one that frees its new code (`b -> c` before `a -> b`), a new field that takes a freed code is added after that rename, and a cycle (two fields that swapped codes) goes through a temporary code: `a -> tmp_<id>`, `b -> a`, `tmp_<id> -> b`, the first step warning `entity_builder.bundle.rename.via.temporary`. Each rename rewrites the references to its field, so they end up where the bundle has them.
+- **Variables** (every non-empty `ENTITY_BUILDER_VAR_<NAME>` env variable, read by the package itself through `EntityBuilderConfigService.getBundleVariables()`; `config.bundles.variables` adds to them and wins on the same name; a name must match `[A-Za-z_][A-Za-z0-9_]*`, any other is ignored): an export replaces each value (at least 4 characters, longest first, in one pass so a written placeholder is never rewritten) with `${var:NAME}`, and an import puts this environment's value back. Only a step's settings (`config`) are rewritten, never its id, type, name or position. A placeholder this environment does not define blocks the import. Use variables for URLs, IDs, tokens and other values that differ per environment, such as an `emailConfigId`. Keep values distinctive: a short common word would be replaced wherever it appears in a step's settings.
+- **Read-only designer** (the `ENTITY_BUILDER_READ_ONLY=true` env variable, read by the package itself through `isDesignerReadOnly()`, for production; `config.designer.readOnly` wins when set): `create-entity`, `apply-change`, `apply-destructive-change` and flow `insert` / `update` / `delete` / `publish` / `restore-version` / `discard-draft` answer **423** `entity_builder.designer.read.only` (`DesignerWritableInterceptor` + `@DesignerWrites`; an interceptor, so it runs after every guard: a caller not signed in or without the permission still gets 401 / 403). Imports, every read, and a `repair` through `apply-change` (it fixes drift without changing a definition) still work, so production changes only from git.
+- **Uploaded as a file**: `plan-import` and `apply-import` take the bundle as a `multipart/form-data` upload (field `bundle`), with `deprecateMissingFields`, `confirm`, `expectedChecksum` and `expectedPlanChecksum` as form fields (`true` / `false` as text). Express's JSON parser never reads a multipart body, so the app's JSON body limit (100kb by default) never applies. The package enforces its own limit, `ENTITY_BUNDLE_MAX_BYTES` (20 MB, `@flusys/nestjs-entity-builder/config`, 413 above it), through `FileInterceptor`. **An app needs no setup in `main.ts`.** `readBundleFile()` parses the file (a UTF-8 BOM is allowed) and validates it as strictly as a request body: unknown keys are refused, and every problem comes back in `errors` named by its path (`entities.0.fields.2.code`), under `entity_builder.bundle.file.invalid`. A missing file answers `entity_builder.bundle.file.required`.
+
+Recommended flow: design in dev → export → commit the bundle in a PR (reviewers read the diff) → CI runs `entity-bundle plan` then `entity-bundle apply` against staging → smoke-test → the same commit runs `apply` against production, where `--confirm` is a manual approval. `scripts/entity-bundle.js` reads `FLUSYS_API_URL`, `FLUSYS_API_TOKEN` and optionally `FLUSYS_TENANT_ID` / `FLUSYS_TENANT_HEADER`. It writes new API keys to a `0600` file (`--keys-out`, git-ignored by default) and never prints them. Exit codes: 1 when blocked, unreachable or failed, 2 when the plan may lose data and `--confirm` was not given.
+
 ## Messages and localization
 
 Every user-facing message is key based (`config/message-keys.ts`, keys `entity_builder.*`): exceptions and responses carry `messageKey` (+ `messageVariables`), and diagnostics (plan `warnings`/`blockers`/step descriptions/`impact`, drift `findings`, flow validation `errors`/`warnings`, run `trace[].error`, record `errors[]`) are `IMessageRef`s from `@flusys/nestjs-shared`, never text. The CRUD controllers use `entityName: 'entity_builder.<resource>'` so the base controller's `*.success` keys match the constants. The English text and the Bengali/Arabic translations live in the app's seed (`flusysnest/src/persistence/localization/entity-builder.localization.ts`, module `entityBuilder`); the frontend `ENTITY_BUILDER_MESSAGES` carries the same English text. Adding a message means adding the constant and both entries.

package/config/entity-builder.constants.d.ts

@@ -1,4 +1,6 @@
 export declare const ENTITY_BUILDER_MODULE_OPTIONS = "ENTITY_BUILDER_MODULE_OPTIONS";
+export declare const ENTITY_BUNDLE_MAX_BYTES: number;
+export declare const BUNDLE_VARIABLE_NAME_PATTERN: RegExp;
 export declare const ENTITY_CODE_PATTERN: RegExp;
 export declare const ENTITY_CODE_MAX_LENGTH = 63;
 export declare const ENTITY_TABLE_PREFIX = "eb_";

package/config/message-keys.d.ts

@@ -56,6 +56,7 @@ export declare const GENERIC_RECORD_MESSAGES: {
     readonly FILTER_OPERATOR_UNKNOWN: "entity_builder.generic_record.filter.operator.unknown";
     readonly FILTER_VALUE_INVALID: "entity_builder.generic_record.filter.value.invalid";
     readonly FILTER_TOO_MANY_VALUES: "entity_builder.generic_record.filter.too.many.values";
+    readonly FILTER_OPERATOR_NOT_FOR_FIELD: "entity_builder.generic_record.filter.operator.not.for.field";
 };
 export declare const SCHEMA_MESSAGES: {
     readonly BUSY: "entity_builder.schema.busy";
@@ -256,15 +257,9 @@ export declare const FLOW_MESSAGES: {
     readonly SLUG_TAKEN: "entity_builder.flow.slug.taken";
     readonly RATE_LIMITED: "entity_builder.flow.rate.limited";
     readonly API_KEY_INVALID: "entity_builder.flow.api.key.invalid";
-    readonly API_KEY_NOT_FOUND: "entity_builder.flow.api.key.not.found";
-    readonly API_KEY_CREATE_SUCCESS: "entity_builder.flow.api.key.create.success";
-    readonly API_KEY_LIST_SUCCESS: "entity_builder.flow.api.key.list.success";
-    readonly API_KEY_REVOKE_SUCCESS: "entity_builder.flow.api.key.revoke.success";
-    readonly API_KEY_DELETE_SUCCESS: "entity_builder.flow.api.key.delete.success";
-    readonly API_KEY_EXPIRED: "entity_builder.flow.api.key.expired";
-    readonly API_KEY_EXPIRY_IN_PAST: "entity_builder.flow.api.key.expiry.in.past";
     readonly CALLED_BY_OTHER_FLOWS: "entity_builder.flow.called.by.other.flows";
     readonly ENDPOINT_CALLED_BY_OTHER_FLOWS: "entity_builder.flow.endpoint.called.by.other.flows";
+    readonly CALLERS_BROKEN: "entity_builder.flow.callers.broken";
     readonly EXECUTION_NOT_FOUND: "entity_builder.flow.execution.not.found";
     readonly EXECUTIONS_SUCCESS: "entity_builder.flow.executions.success";
     readonly EXECUTION_SUCCESS: "entity_builder.flow.execution.success";
@@ -282,6 +277,14 @@ export declare const FLOW_MESSAGES: {
     readonly INPUT_BODY_ITEM_NOT_OBJECT: "entity_builder.flow.input.body.item.not.object";
     readonly CHECKS_FAILED: "entity_builder.flow.checks.failed";
     readonly PERMISSION_DENIED: "entity_builder.flow.permission.denied";
+    readonly PUBLISH_SUCCESS: "entity_builder.flow.publish.success";
+    readonly NOTHING_TO_PUBLISH: "entity_builder.flow.nothing.to.publish";
+    readonly VERSIONS_SUCCESS: "entity_builder.flow.versions.success";
+    readonly VERSION_SUCCESS: "entity_builder.flow.version.success";
+    readonly VERSION_NOT_FOUND: "entity_builder.flow.version.not.found";
+    readonly VERSION_RESTORED: "entity_builder.flow.version.restored";
+    readonly DRAFT_DISCARDED: "entity_builder.flow.draft.discarded";
+    readonly NO_DRAFT: "entity_builder.flow.no.draft";
 };
 export declare const FLOW_ERROR_MESSAGES: {
     readonly NO_TRIGGER: "entity_builder.flow.error.no.trigger";
@@ -317,21 +320,34 @@ export declare const FLOW_ERROR_MESSAGES: {
     readonly CALLED_FLOW_TOO_DEEP: "entity_builder.flow.error.called.flow.too.deep";
     readonly CALLED_FLOW_FAILED: "entity_builder.flow.error.called.flow.failed";
     readonly CALLED_FLOW_FAILED_AT_NODE: "entity_builder.flow.error.called.flow.failed.at.node";
-    readonly RUN_AS_NOT_ALLOWED: "entity_builder.flow.error.run.as.not.allowed";
     readonly FILTER_VALUE_MISSING: "entity_builder.flow.error.filter.value.missing";
+    readonly TOO_MANY_MESSAGES: "entity_builder.flow.error.too.many.messages";
+    readonly TOO_MANY_RECIPIENTS: "entity_builder.flow.error.too.many.recipients";
+    readonly NOTIFICATION_UNAVAILABLE: "entity_builder.flow.error.notification.unavailable";
+    readonly NOTIFICATION_RECIPIENT_INVALID: "entity_builder.flow.error.notification.recipient.invalid";
+    readonly NOTIFICATION_COMPANY_INVALID: "entity_builder.flow.error.notification.company.invalid";
+    readonly NOTIFICATION_BRANCH_INVALID: "entity_builder.flow.error.notification.branch.invalid";
+    readonly NOTIFICATION_COMPANY_UNAVAILABLE: "entity_builder.flow.error.notification.company.unavailable";
+    readonly NOTIFICATION_TITLE_EMPTY: "entity_builder.flow.error.notification.title.empty";
+    readonly NOTIFICATION_FAILED: "entity_builder.flow.error.notification.failed";
+    readonly EMAIL_UNAVAILABLE: "entity_builder.flow.error.email.unavailable";
+    readonly EMAIL_ADDRESS_INVALID: "entity_builder.flow.error.email.address.invalid";
+    readonly EMAIL_SUBJECT_EMPTY: "entity_builder.flow.error.email.subject.empty";
+    readonly EMAIL_BODY_EMPTY: "entity_builder.flow.error.email.body.empty";
+    readonly EMAIL_FAILED: "entity_builder.flow.error.email.failed";
 };
 export declare const FLOW_SKIP_MESSAGES: {
     readonly HTTP: "entity_builder.flow.skip.http";
     readonly EVENTS: "entity_builder.flow.skip.events";
+    readonly NOTIFICATION: "entity_builder.flow.skip.notification";
+    readonly EMAIL: "entity_builder.flow.skip.email";
+    readonly NO_RECIPIENTS: "entity_builder.flow.skip.no.recipients";
     readonly COMMIT_DRY_RUN: "entity_builder.flow.skip.commit.dry.run";
     readonly COMMIT_NO_TRANSACTION: "entity_builder.flow.skip.commit.no.transaction";
     readonly COMMIT_JOINED: "entity_builder.flow.skip.commit.joined";
 };
 export declare const FLOW_VALIDATION_MESSAGES: {
     readonly SLUG_INVALID: "entity_builder.flow.validation.slug.invalid";
-    readonly RUN_AS_CALLER_NEEDS_AUTH: "entity_builder.flow.validation.run.as.caller.needs.auth";
-    readonly RUN_AS_INVALID: "entity_builder.flow.validation.run.as.invalid";
-    readonly AUTH_MODE_INVALID: "entity_builder.flow.validation.auth.mode.invalid";
     readonly NO_NODES: "entity_builder.flow.validation.no.nodes";
     readonly TOO_MANY_NODES: "entity_builder.flow.validation.too.many.nodes";
     readonly TOO_MANY_EDGES: "entity_builder.flow.validation.too.many.edges";
@@ -356,8 +372,17 @@ export declare const FLOW_VALIDATION_MESSAGES: {
     readonly COMMIT_NOT_TRANSACTIONAL: "entity_builder.flow.validation.commit.not.transactional";
     readonly COMMIT_IN_LOOP: "entity_builder.flow.validation.commit.in.loop";
     readonly COMMIT_IN_CALLED_FLOW: "entity_builder.flow.validation.commit.in.called.flow";
-    readonly PUBLIC_SYSTEM_ENTITY: "entity_builder.flow.validation.public.system.entity";
     readonly PERMISSION_WITHOUT_USER: "entity_builder.flow.validation.permission.without.user";
+    readonly KEYLESS_ENTITY: "entity_builder.flow.validation.keyless.entity";
+    readonly TRIGGER_AUTH_INVALID: "entity_builder.flow.validation.trigger.auth.invalid";
+    readonly TRIGGER_TRANSACTION_INVALID: "entity_builder.flow.validation.trigger.transaction.invalid";
+    readonly TRIGGER_TIMEOUT_RANGE: "entity_builder.flow.validation.trigger.timeout.range";
+    readonly TRIGGER_RATE_LIMIT_RANGE: "entity_builder.flow.validation.trigger.rate.limit.range";
+    readonly TRIGGER_API_KEY_REQUIRED: "entity_builder.flow.validation.trigger.api.key.required";
+    readonly TRIGGER_API_KEY_INVALID: "entity_builder.flow.validation.trigger.api.key.invalid";
+    readonly NODE_FORWARDS_TOKEN: "entity_builder.flow.validation.node.forwards.token";
+    readonly NODE_ACCESS_TARGET_REQUIRED: "entity_builder.flow.validation.node.access.target.required";
+    readonly NODE_ACCESS_USER_REQUIRED: "entity_builder.flow.validation.node.access.user.required";
     readonly INPUT_TOO_MANY: "entity_builder.flow.validation.input.too.many";
     readonly INPUT_NAME_INVALID: "entity_builder.flow.validation.input.name.invalid";
     readonly INPUT_NAME_DUPLICATE: "entity_builder.flow.validation.input.name.duplicate";
@@ -379,6 +404,7 @@ export declare const FLOW_VALIDATION_MESSAGES: {
     readonly NODE_CASE_DUPLICATE: "entity_builder.flow.validation.node.case.duplicate";
     readonly NODE_MAX_ITEMS_RANGE: "entity_builder.flow.validation.node.max.items.range";
     readonly NODE_LIMIT_RANGE: "entity_builder.flow.validation.node.limit.range";
+    readonly NODE_SORT_INVALID: "entity_builder.flow.validation.node.sort.invalid";
     readonly NODE_WRITE_TARGET_INVALID: "entity_builder.flow.validation.node.write.target.invalid";
     readonly NODE_NOT_FOUND_INVALID: "entity_builder.flow.validation.node.not.found.invalid";
     readonly NODE_FILTER_REQUIRED: "entity_builder.flow.validation.node.filter.required";
@@ -403,6 +429,15 @@ export declare const FLOW_VALIDATION_MESSAGES: {
     readonly NODE_CHOOSE_METHOD: "entity_builder.flow.validation.node.choose.method";
     readonly NODE_TIMEOUT_RANGE: "entity_builder.flow.validation.node.timeout.range";
     readonly NODE_EVENT_NAME_INVALID: "entity_builder.flow.validation.node.event.name.invalid";
+    readonly NODE_NOTIFICATION_UNAVAILABLE: "entity_builder.flow.validation.node.notification.unavailable";
+    readonly NODE_NOTIFICATION_OPTION_INVALID: "entity_builder.flow.validation.node.notification.option.invalid";
+    readonly NODE_NOTIFICATION_COMPANY_UNAVAILABLE: "entity_builder.flow.validation.node.notification.company.unavailable";
+    readonly NODE_MESSAGE_TARGET_INVALID: "entity_builder.flow.validation.node.message.target.invalid";
+    readonly NODE_EMAIL_UNAVAILABLE: "entity_builder.flow.validation.node.email.unavailable";
+    readonly NODE_EMAIL_OPTION_INVALID: "entity_builder.flow.validation.node.email.option.invalid";
+    readonly NODE_EMAIL_TEMPLATE_REQUIRED: "entity_builder.flow.validation.node.email.template.required";
+    readonly MESSAGE_AFTER_COMMIT: "entity_builder.flow.validation.message.after.commit";
+    readonly PUBLIC_MESSAGE: "entity_builder.flow.validation.public.message";
     readonly NODE_STATUS_2XX_5XX: "entity_builder.flow.validation.node.status.2xx.5xx";
     readonly REF_BAD_SCOPE: "entity_builder.flow.validation.ref.bad.scope";
     readonly REF_NODE_MISSING: "entity_builder.flow.validation.ref.node.missing";
@@ -456,6 +491,7 @@ export declare const FLOW_SHAPE_MESSAGES: {
     readonly LOOKUP_FIELD_INVALID: "entity_builder.flow.shape.lookup.field.invalid";
     readonly FILTER_OPERATOR_UNKNOWN: "entity_builder.flow.shape.filter.operator.unknown";
     readonly FILTER_VALUE_REQUIRED: "entity_builder.flow.shape.filter.value.required";
+    readonly FILTER_RANGE_INVALID: "entity_builder.flow.shape.filter.range.invalid";
 };
 export declare const FLOW_SUBJECT_MESSAGES: {
     readonly THE_RULE: "entity_builder.flow.subject.the.rule";
@@ -470,6 +506,23 @@ export declare const FLOW_SUBJECT_MESSAGES: {
     readonly THE_URL: "entity_builder.flow.subject.the.url";
     readonly THE_INPUT_LIST: "entity_builder.flow.subject.the.input.list";
     readonly THE_RESPONSE: "entity_builder.flow.subject.the.response";
+    readonly THE_RECIPIENTS: "entity_builder.flow.subject.the.recipients";
+    readonly THE_TITLE: "entity_builder.flow.subject.the.title";
+    readonly THE_MESSAGE: "entity_builder.flow.subject.the.message";
+    readonly THE_COMPANY: "entity_builder.flow.subject.the.company";
+    readonly THE_COMPANIES: "entity_builder.flow.subject.the.companies";
+    readonly THE_BRANCHES: "entity_builder.flow.subject.the.branches";
+    readonly THE_BRANCH: "entity_builder.flow.subject.the.branch";
+    readonly THE_USER: "entity_builder.flow.subject.the.user";
+    readonly THE_CC: "entity_builder.flow.subject.the.cc";
+    readonly THE_BCC: "entity_builder.flow.subject.the.bcc";
+    readonly THE_REPLY_TO: "entity_builder.flow.subject.the.reply.to";
+    readonly THE_SUBJECT: "entity_builder.flow.subject.the.subject";
+    readonly THE_BODY: "entity_builder.flow.subject.the.body";
+    readonly DATA_VALUES: "entity_builder.flow.subject.data.values";
+    readonly DATA_VALUE: "entity_builder.flow.subject.data.value";
+    readonly TEMPLATE_VALUES: "entity_builder.flow.subject.template.values";
+    readonly TEMPLATE_VALUE: "entity_builder.flow.subject.template.value";
     readonly VARIABLES: "entity_builder.flow.subject.variables";
     readonly VARIABLE: "entity_builder.flow.subject.variable";
     readonly FIELDS: "entity_builder.flow.subject.fields";
@@ -487,3 +540,34 @@ export declare const FLOW_SUBJECT_MESSAGES: {
     readonly RESPONSE_VALUES: "entity_builder.flow.subject.response.values";
     readonly RESPONSE_VALUE: "entity_builder.flow.subject.response.value";
 };
+export declare const BUNDLE_MESSAGES: {
+    readonly SETTINGS_SUCCESS: "entity_builder.bundle.settings.success";
+    readonly EXPORT_SUCCESS: "entity_builder.bundle.export.success";
+    readonly PLAN_SUCCESS: "entity_builder.bundle.plan.success";
+    readonly APPLY_SUCCESS: "entity_builder.bundle.apply.success";
+    readonly APPLY_PARTIAL: "entity_builder.bundle.apply.partial";
+    readonly APPLY_BLOCKED: "entity_builder.bundle.apply.blocked";
+    readonly CHECKSUM_MISMATCH: "entity_builder.bundle.checksum.mismatch";
+    readonly PLAN_CHANGED: "entity_builder.bundle.plan.changed";
+    readonly PLAN_CHECKSUM_REQUIRED: "entity_builder.bundle.plan.checksum.required";
+    readonly ENTITY_DRAFT_IN_BUNDLE: "entity_builder.bundle.entity.draft.in.bundle";
+    readonly ENTITY_DRAFT_HERE: "entity_builder.bundle.entity.draft.here";
+    readonly ENTITY_DRAFT_SKIPPED: "entity_builder.bundle.entity.draft.skipped";
+    readonly RENAME_VIA_TEMPORARY: "entity_builder.bundle.rename.via.temporary";
+    readonly FILE_REQUIRED: "entity_builder.bundle.file.required";
+    readonly FILE_INVALID: "entity_builder.bundle.file.invalid";
+    readonly CONFIRM_REQUIRED: "entity_builder.bundle.confirm.required";
+    readonly DUPLICATE_ENTITY: "entity_builder.bundle.duplicate.entity";
+    readonly DUPLICATE_FIELD: "entity_builder.bundle.duplicate.field";
+    readonly DUPLICATE_FLOW: "entity_builder.bundle.duplicate.flow";
+    readonly RELATION_TARGET_UNKNOWN: "entity_builder.bundle.relation.target.unknown";
+    readonly ENTITY_CODE_CHANGED: "entity_builder.bundle.entity.code.changed";
+    readonly VARIABLE_MISSING: "entity_builder.bundle.variable.missing";
+    readonly FLOW_SLUG_DELETED: "entity_builder.bundle.flow.slug.deleted";
+    readonly FLOW_UNPUBLISHED_SKIPPED: "entity_builder.bundle.flow.unpublished.skipped";
+    readonly FLOW_DRAFT_REPLACED: "entity_builder.bundle.flow.draft.replaced";
+    readonly FLOW_API_KEY_GENERATED: "entity_builder.bundle.flow.api.key.generated";
+    readonly STEP_AFTER_EARLIER: "entity_builder.bundle.step.after.earlier";
+    readonly FLOWS_CHECKED_ON_APPLY: "entity_builder.bundle.flows.checked.on.apply";
+    readonly DESIGNER_READ_ONLY: "entity_builder.designer.read.only";
+};

package/controllers/definition-bundle.controller.d.ts

@@ -0,0 +1,15 @@
+import { type ILoggedUserInfo, SingleResponseDto } from '@flusys/nestjs-shared';
+import { ExportBundleDto, ImportBundleOptionsDto } from '../dtos/definition-bundle.dto.js';
+import { type IBundleExport, type IBundleImportPlan, type IBundleImportResult, type IBundleSettings } from '../interfaces/definition-bundle.interface.js';
+import { type IUploadedBundleFile } from '../services/definition-bundle.file.js';
+import { DefinitionBundleService } from '../services/definition-bundle.service.js';
+import { EntityBuilderConfigService } from '../services/entity-builder-config.service.js';
+export declare class DefinitionBundleController {
+    private readonly bundles;
+    private readonly config;
+    constructor(bundles: DefinitionBundleService, config: EntityBuilderConfigService);
+    settings(): SingleResponseDto<IBundleSettings>;
+    export(dto: ExportBundleDto): Promise<SingleResponseDto<IBundleExport>>;
+    planImport(file: IUploadedBundleFile | undefined, options: ImportBundleOptionsDto, user: ILoggedUserInfo): Promise<SingleResponseDto<IBundleImportPlan>>;
+    applyImport(file: IUploadedBundleFile | undefined, options: ImportBundleOptionsDto, user: ILoggedUserInfo): Promise<SingleResponseDto<IBundleImportResult>>;
+}

package/controllers/flow-definition.controller.d.ts

@@ -1,5 +1,6 @@
 import { type ILoggedUserInfo, SingleResponseDto } from '@flusys/nestjs-shared';
-import { CreateFlowDefinitionDto, FlowDefinitionResponseDto, TestFlowDto, UpdateFlowDefinitionDto, ValidateFlowDto } from '../dtos/flow.dto.js';
+import { CreateFlowDefinitionDto, FlowDefinitionResponseDto, FlowIdDto, FlowVersionRefDto, PublishFlowDto, TestFlowDto, UpdateFlowDefinitionDto, ValidateFlowDto } from '../dtos/flow.dto.js';
+import { type IFlowDefinition, type IFlowVersion } from '../interfaces/flow-definition.interface.js';
 import { type IFlowValidationResult } from '../flow-engine/flow-graph.validator.js';
 import { FlowDefinitionService } from '../services/flow-definition.service.js';
 import { FlowRuntimeService } from '../services/flow-runtime.service.js';
@@ -23,6 +24,11 @@ export declare class FlowDefinitionController extends FlowDefinitionController_b
     private readonly runtime;
     constructor(flowDefinitionService: FlowDefinitionService, runtime: FlowRuntimeService);
     validate(dto: ValidateFlowDto): Promise<SingleResponseDto<IFlowValidationResult>>;
+    publish(dto: PublishFlowDto, user: ILoggedUserInfo): Promise<SingleResponseDto<IFlowDefinition>>;
+    versions(dto: FlowIdDto): Promise<SingleResponseDto<IFlowVersion[]>>;
+    version(dto: FlowVersionRefDto): Promise<SingleResponseDto<IFlowVersion>>;
+    restoreVersion(dto: FlowVersionRefDto, user: ILoggedUserInfo): Promise<SingleResponseDto<IFlowDefinition>>;
+    discardDraft(dto: FlowIdDto, user: ILoggedUserInfo): Promise<SingleResponseDto<IFlowDefinition>>;
     testRun(dto: TestFlowDto, user: ILoggedUserInfo, req: {
         ip?: string;
         headers: Record<string, unknown>;