@uipath/maestro-builder-sdk 6.6.1 → 6.8.0

package/dist/core/actions.d.ts

@@ -1401,7 +1401,7 @@ export interface InlineAgentInputs {
      * argument after the reference PATH, `__`-joined. For a flow input the two
      * coincide (`$vars.notes` → `notes`); for a step output they do not, and a sidecar
      * still saying `{{input.claim}}` templates against a key that is not there — the
-     * literal text reaches the model. See `skill/references/inline-agent.md`
+     * literal text reaches the model. See the inline-agent node reference (`website/reference/inline-agent.md`)
      * §"The three prompt DIALECTS".
      *
      * If the agent has to answer in a shape the flow then reads, say so here. The
@@ -2016,46 +2016,215 @@ export interface QueueItemInputs {
      */
     returns?: Record<string, ReturnFieldType>;
 }
-/** One filter row on a Data Fabric read — rows AND together unless `or` is set. */
+/**
+ * The comparison operators the Data Fabric query serializer can emit, spelled
+ * exactly as the file carries them.
+ *
+ * @remarks
+ * There is deliberately no `not in`, `not contains`, or null check — the
+ * serializer cannot emit them, and a filter it cannot emit takes the WHOLE
+ * query down rather than dropping one row. `is any of` is the legacy spelling
+ * of `in` and is still read, but author `in`.
+ */
+export type DataFabricOperator = '=' | '!=' | '>' | '>=' | '<' | '<=' | 'contains' | 'starts with' | 'ends with' | 'in';
+/** One filter row on a Data Fabric query — rows AND together unless `or` is set. */
 export interface DataFabricFilter {
-    /** The entity column to filter on. */
+    /**
+     * The entity column to filter on. A dotted related path (`customer.Name`) is
+     * capped at 3 segments and needs the canvas's `_entityFields` snapshot, which
+     * the SDK does not author — keep from-scratch filters on the entity's own
+     * columns.
+     */
     field: string;
-    /** Comparison operator the designer offers — `=` (the default), `!=`, `>`, `>=`, `<`, `<=`, `contains`, … */
-    operator?: string;
-    /** The comparison value. An `Expr` re-evaluates at activation time. */
+    /** Comparison operator; `=` when omitted. */
+    operator?: DataFabricOperator;
+    /**
+     * The comparison value. An `Expr` re-evaluates at activation time.
+     *
+     * A choice-set column compares against the choice's numeric `numberId`, never
+     * its label — a label matches nothing.
+     */
     value: string | Expr;
-    /** Join this row to the PREVIOUS one with OR instead of AND. */
+    /**
+     * Start a new OR alternative at this row.
+     *
+     * @remarks
+     * The query model is disjunctive — `alt1 OR alt2 OR …`, each alternative an
+     * AND of its own rows — so `or` SPLITS the list rather than joining one row
+     * to the one before it. `[A, B(or), C]` is therefore `A OR (B AND C)`, not
+     * `(A OR B) AND C`; to get the latter, write it out as
+     * `(A AND C) OR (B AND C)`.
+     *
+     * Ignored on the first row, which has no earlier alternative to split from.
+     */
     or?: boolean;
 }
+/** How a multi-record query orders its rows before the limit is applied. */
+export interface DataFabricSort {
+    /** The column to order by — a real one; a sort on a missing column is not caught by `validate`. */
+    field: string;
+    /** `'asc'` when omitted. */
+    direction?: 'asc' | 'desc';
+}
+/**
+ * Which record a Data Fabric write targets — exactly ONE of the two forms.
+ *
+ * @remarks
+ * `{ byId }` names a record id, literal or expression. `{ fromRead }` names an
+ * earlier {@link dataFabricRead} STEP and reuses the record that step found, so
+ * the id never has to be carried by hand; `check` rejects a name no read step
+ * has. Shared by {@link dataFabricUpdate} and {@link dataFabricDelete} — the
+ * platform gives them the same `recordSource` shape.
+ */
+export type DataFabricRecordRef = {
+    byId: string | Expr;
+    fromRead?: never;
+} | {
+    fromRead: string;
+    byId?: never;
+};
 export interface DataFabricReadInputs {
     /** The Data Fabric entity's name, e.g. `'Invoices'`. */
     entity: string;
-    /** Filter rows selecting the record to read. Omit to read the first record. */
+    /** Filter rows selecting the record(s) to query. Omit to take everything the entity holds. */
     filters?: DataFabricFilter[];
-    /** Folder key (GUID) for folder-scoped entities. */
+    /**
+     * `'single'` publishes ONE record as the step's `output`; `'multiple'`
+     * publishes the matching records under `output.results`.
+     *
+     * Setting either selects the node's **1.4** definition, which is where
+     * `resultMode` exists at all — the SDK's pinned default is 1.0, the
+     * read-one-record node this family started as. Omit it and nothing changes:
+     * the step stays on 1.0 and reads one record, as it always did.
+     *
+     * A `'single'` read faults only on an OVER-match; zero matches completes
+     * normally and leaves the step's output unresolved, so treat "not found" as a
+     * branch rather than an error.
+     */
+    resultMode?: 'single' | 'multiple';
+    /**
+     * Row cap for a `'multiple'` query. The emitted query ALWAYS carries a limit:
+     * omitting this resolves to 100, and 1000 is a hard ceiling — a larger value
+     * truncates silently, so page with `skip` instead.
+     */
+    limit?: number;
+    /** Rows to skip before the limit — the paging half of `limit`. */
+    skip?: number;
+    /** Order rows before the limit applies. Without it a limited slice is arbitrary. */
+    sort?: DataFabricSort;
+    /** Only these columns. Omit for every column the entity has. */
+    fields?: string[];
+    /**
+     * Folder key (GUID) for a folder-scoped entity — its `folderId` from
+     * `uip df entities list --include-folders`.
+     *
+     * Requires `resourceKey`: `folderKey` alone serializes the folder as a
+     * source-org LITERAL, which looks portable and breaks on cross-org deploy, so
+     * `check` refuses the pair being half-authored.
+     */
     folderKey?: string;
+    /**
+     * The key the entity's reference is registered under in the solution, from
+     * `uip solution resources list --kind Entity`.
+     *
+     * @remarks
+     * Only meaningful with `folderKey`. Supplying both emits the two
+     * `resource: 'Entity'` binding rows (`propertyAttribute` `name` and
+     * `folderKey`) that let the flow deploy to another org. Nothing mints this
+     * key for a hand-authored flow — if you cannot resolve one, keep the entity
+     * tenant-scoped and omit both.
+     */
+    resourceKey?: string;
 }
-export interface DataFabricUpdateInputs {
+export interface DataFabricCreateInputs {
     /** The Data Fabric entity's name, e.g. `'Invoices'`. */
     entity: string;
     /**
-     * Which record to update: `{ byId: <record id> }`, or `{ fromRead: '<step>' }`
-     * naming an earlier `dataFabricRead` step whose record this write targets.
+     * The columns the new record starts with, by field name. At least one is
+     * required — the node's schema rejects an empty field list rather than
+     * inserting a blank row.
      */
-    record: {
-        byId: string | Expr;
-        fromRead?: never;
-    } | {
-        fromRead: string;
-        byId?: never;
-    };
+    values: Record<string, string | Expr>;
+    /**
+     * Folder key (GUID) for a folder-scoped entity — its `folderId` from
+     * `uip df entities list --include-folders`.
+     *
+     * Requires `resourceKey`: `folderKey` alone serializes the folder as a
+     * source-org LITERAL, which looks portable and breaks on cross-org deploy, so
+     * `check` refuses the pair being half-authored.
+     */
+    folderKey?: string;
+    /**
+     * The key the entity's reference is registered under in the solution, from
+     * `uip solution resources list --kind Entity`.
+     *
+     * @remarks
+     * Only meaningful with `folderKey`. Supplying both emits the two
+     * `resource: 'Entity'` binding rows (`propertyAttribute` `name` and
+     * `folderKey`) that let the flow deploy to another org. Nothing mints this
+     * key for a hand-authored flow — if you cannot resolve one, keep the entity
+     * tenant-scoped and omit both.
+     */
+    resourceKey?: string;
+}
+export interface DataFabricUpdateInputs {
+    /** The Data Fabric entity's name, e.g. `'Invoices'`. */
+    entity: string;
+    /** Which record to update — see {@link DataFabricRecordRef}. */
+    record: DataFabricRecordRef;
     /**
      * The columns to write, by field name. An empty string is a real write — it
      * clears the column.
      */
     set: Record<string, string | Expr>;
-    /** Folder key (GUID) for folder-scoped entities. */
+    /**
+     * Folder key (GUID) for a folder-scoped entity — its `folderId` from
+     * `uip df entities list --include-folders`.
+     *
+     * Requires `resourceKey`: `folderKey` alone serializes the folder as a
+     * source-org LITERAL, which looks portable and breaks on cross-org deploy, so
+     * `check` refuses the pair being half-authored.
+     */
+    folderKey?: string;
+    /**
+     * The key the entity's reference is registered under in the solution, from
+     * `uip solution resources list --kind Entity`.
+     *
+     * @remarks
+     * Only meaningful with `folderKey`. Supplying both emits the two
+     * `resource: 'Entity'` binding rows (`propertyAttribute` `name` and
+     * `folderKey`) that let the flow deploy to another org. Nothing mints this
+     * key for a hand-authored flow — if you cannot resolve one, keep the entity
+     * tenant-scoped and omit both.
+     */
+    resourceKey?: string;
+}
+export interface DataFabricDeleteInputs {
+    /** The Data Fabric entity's name, e.g. `'Invoices'`. */
+    entity: string;
+    /** Which record to delete — see {@link DataFabricRecordRef}. */
+    record: DataFabricRecordRef;
+    /**
+     * Folder key (GUID) for a folder-scoped entity — its `folderId` from
+     * `uip df entities list --include-folders`.
+     *
+     * Requires `resourceKey`: `folderKey` alone serializes the folder as a
+     * source-org LITERAL, which looks portable and breaks on cross-org deploy, so
+     * `check` refuses the pair being half-authored.
+     */
     folderKey?: string;
+    /**
+     * The key the entity's reference is registered under in the solution, from
+     * `uip solution resources list --kind Entity`.
+     *
+     * @remarks
+     * Only meaningful with `folderKey`. Supplying both emits the two
+     * `resource: 'Entity'` binding rows (`propertyAttribute` `name` and
+     * `folderKey`) that let the flow deploy to another org. Nothing mints this
+     * key for a hand-authored flow — if you cannot resolve one, keep the entity
+     * tenant-scoped and omit both.
+     */
+    resourceKey?: string;
 }
 export interface DocumentClassifyInputs {
     /** The document to classify — a file reference (`input('file')`, `out('fetch', 'fileRef')`, …). */
@@ -2191,9 +2360,15 @@ export type ActionSpec = {
 } | {
     kind: 'dataFabricRead';
     inputs: DataFabricReadInputs;
+} | {
+    kind: 'dataFabricCreate';
+    inputs: DataFabricCreateInputs;
 } | {
     kind: 'dataFabricUpdate';
     inputs: DataFabricUpdateInputs;
+} | {
+    kind: 'dataFabricDelete';
+    inputs: DataFabricDeleteInputs;
 } | {
     kind: 'waitEvent';
     subscription: EventSubscription;
@@ -2436,7 +2611,7 @@ export declare function batchTransform(inputs: BatchTransformInputs): ActionSpec
  * with zero envelopes among them. The RUNTIME
  * accepts both, so only `uip maestro flow validate` sees a wrong one; the
  * emitter's exemption lives in `migrate.ts` (`UNWRAPPED_INPUTS`).
- * See `skill/references/ixp.md` §3.
+ * See the IxP node reference (`website/reference/ixp.md`) §3.
  *
  * @example
  * **Extract an invoice total and read it out of the nested result**
@@ -2929,63 +3104,97 @@ export declare function documentClassify(inputs: DocumentClassifyInputs): Action
  */
 export declare function dynamicExtract(inputs: DynamicExtractInputs): ActionSpec;
 /**
- * Read ONE entity record from Data Fabric (`core.datafabric.read`). The record
+ * Query entity records from Data Fabric (`core.datafabric.read`). The result
  * publishes to the step's `output`; downstream references re-fetch fresh data
  * at activation time (the engine re-runs the query rather than caching).
  *
  * @remarks
- * **Prefer the connector for Data Fabric work during the transition.**
- * `core.datafabric.*` has exactly two verbs — this one and
- * {@link dataFabricUpdate} — and neither declares an output schema. Create,
- * delete, get-by-id, a multi-record query with a row limit, file record fields
- * and entity events are NOT in this family: they are operations on the SAME
- * product reached through its Integration Service connector,
+ * This node is **read-one AND query-many**, on its 1.4 definition: `resultMode:
+ * 'multiple'` publishes the matching records under `output.results`, and the
+ * platform renames the node "Query entity records" to say so. The SDK still
+ * pins 1.0 — read-one — as the no-`{ version }` default, so passing
+ * `resultMode` is what selects 1.4; see {@link DataFabricReadInputs.resultMode}.
+ *
+ * The native family covers all four CRUD verbs: this one,
+ * {@link dataFabricCreate}, {@link dataFabricUpdate} and
+ * {@link dataFabricDelete}. What it does NOT cover is get-by-id, a query row
+ * limit, file record fields, and entity events — those are operations on the
+ * SAME product reached through its Integration Service connector,
  * `uipath-uipath-dataservice` (the tenant displays it as **UiPath Data
- * Fabric**), which covers every verb including the two here.
- *
- * Taking this node for the one verb that has a native form leaves the rest of
- * the same entity on the connector — two connection bindings and two payload
- * shapes in one flow. So route entity work through the connector unless the
- * scenario names these nodes; native forms for the remaining verbs are the
- * direction of travel, and this guidance changes when they land. `check` does
- * not reject a native node — this is a routing default, not a rule:
+ * Fabric**). So a flow that needs one of those still straddles two surfaces,
+ * and the connector remains the one surface that covers everything:
  *
  * ```ts
- * .step('create', connector('uipath-uipath-dataservice', 'create-entity-record',
- *   { entityName: 'Contracts', contractTitle: 'Q3 renewal' }, { connection: 'df' }))
+ * .step('byId', connector('uipath-uipath-dataservice', 'get-entity-record-by-id',
+ *   { entityName: 'Contracts', recordId: input('id') }, { connection: 'df' }))
  * ```
  *
- * That operation's body fields come from the entity, so the library cannot
- * carry them: run `npx flow-sdk registry prepare uipath-uipath-dataservice
- * create-entity-record -f entityName=<Entity>` first (`uip maestro registry
- * prepare …` is the same command when you are driving through the UiPath CLI). The routing table is in
- * the `data-fabric.md` reference and the parent-field loop in
- * `connector-params.md` — cited by name rather than linked, because this
+ * A connector operation's body fields come from the entity, so the library
+ * cannot carry them: run `uip maestro registry prepare uipath-uipath-dataservice
+ * get-entity-record-by-id -f entityName=<Entity>` first (`npx flow-sdk registry
+ * prepare …` is the same command when invoking the package's own bin directly).
+ * The routing table is in the `data-fabric.md` reference and the parent-field
+ * loop in `connector-params.md` — cited by name rather than linked, because this
  * comment renders both into the flat corpus, where those files sit alongside
  * it, and onto the site, where each symbol is its own page and a relative
  * `./data-fabric` resolves to nothing.
  *
- * @param inputs - The entity, optional filter rows, and folder scope.
+ * @param inputs - The entity, optional filter rows, result mode, and folder scope.
  * @returns An action spec to pass to `.step(name, …)`.
  */
 export declare function dataFabricRead(inputs: DataFabricReadInputs): ActionSpec;
+/**
+ * Create an entity record in Data Fabric (`core.datafabric.create`). The new
+ * record publishes to the step's `output`, so a following
+ * {@link dataFabricUpdate} or {@link dataFabricDelete} can read its id.
+ *
+ * @remarks
+ * `values` must name at least one column — the node's schema rejects an empty
+ * field list rather than inserting a blank row, and `check` says so before the
+ * platform does. Field names are the ENTITY's, so copy them from the scenario
+ * or the tenant; nothing offline can tell a real column from a typo.
+ *
+ * See {@link dataFabricRead} for what the native family still does not cover
+ * and which connector operation covers it.
+ *
+ * @param inputs - The entity, the columns the record starts with, and folder scope.
+ * @returns An action spec to pass to `.step(name, …)`.
+ */
+export declare function dataFabricCreate(inputs: DataFabricCreateInputs): ActionSpec;
 /**
  * Update an entity record in Data Fabric (`core.datafabric.update`). Target the
  * record by id or through an earlier {@link dataFabricRead} step; downstream
  * reads of this step observe the record AFTER the write.
  *
  * @remarks
- * The second and last verb of the native family — see {@link dataFabricRead}
- * for what the family does NOT cover, which connector operation covers it
- * instead, and why entity work routes through the connector during the
- * transition. For an update whose flow also creates, gets or deletes on the
- * same entity, use `connector(…, 'update-entity-record', …)` so the flow keeps
- * one surface.
+ * `set` must write at least one column: an empty `set` is a no-op the platform
+ * reports as success, so `check` rejects it.
+ *
+ * See {@link dataFabricRead} for what the native family still does not cover
+ * and which connector operation covers it.
  *
  * @param inputs - The entity, the record selector, and the columns to write.
  * @returns An action spec to pass to `.step(name, …)`.
  */
 export declare function dataFabricUpdate(inputs: DataFabricUpdateInputs): ActionSpec;
+/**
+ * Delete an entity record from Data Fabric (`core.datafabric.delete`). Target
+ * the record by id or through an earlier {@link dataFabricRead} step, exactly
+ * as {@link dataFabricUpdate} does.
+ *
+ * @remarks
+ * A delete **publishes nothing** — its definition declares no output — so
+ * `$vars.<step>.output` is undefined at run time and `check` rejects a read of
+ * it. Take what you need off the read step that found the record, before the
+ * delete.
+ *
+ * See {@link dataFabricRead} for what the native family still does not cover
+ * and which connector operation covers it.
+ *
+ * @param inputs - The entity, the record selector, and folder scope.
+ * @returns An action spec to pass to `.step(name, …)`.
+ */
+export declare function dataFabricDelete(inputs: DataFabricDeleteInputs): ActionSpec;
 /**
  * Declare an Orchestrator QUEUE ITEM step.
  *

package/dist/core/actions.js

@@ -345,7 +345,7 @@ export function batchTransform(inputs) {
  * with zero envelopes among them. The RUNTIME
  * accepts both, so only `uip maestro flow validate` sees a wrong one; the
  * emitter's exemption lives in `migrate.ts` (`UNWRAPPED_INPUTS`).
- * See `skill/references/ixp.md` §3.
+ * See the IxP node reference (`website/reference/ixp.md`) §3.
  *
  * @example
  * **Extract an invoice total and read it out of the nested result**
@@ -891,71 +891,118 @@ export function dynamicExtract(inputs) {
     return builtinActionSpec({ kind: 'dynamicExtract', inputs });
 }
 /**
- * Read ONE entity record from Data Fabric (`core.datafabric.read`). The record
+ * Query entity records from Data Fabric (`core.datafabric.read`). The result
  * publishes to the step's `output`; downstream references re-fetch fresh data
  * at activation time (the engine re-runs the query rather than caching).
  *
  * @remarks
- * **Prefer the connector for Data Fabric work during the transition.**
- * `core.datafabric.*` has exactly two verbs — this one and
- * {@link dataFabricUpdate} — and neither declares an output schema. Create,
- * delete, get-by-id, a multi-record query with a row limit, file record fields
- * and entity events are NOT in this family: they are operations on the SAME
- * product reached through its Integration Service connector,
+ * This node is **read-one AND query-many**, on its 1.4 definition: `resultMode:
+ * 'multiple'` publishes the matching records under `output.results`, and the
+ * platform renames the node "Query entity records" to say so. The SDK still
+ * pins 1.0 — read-one — as the no-`{ version }` default, so passing
+ * `resultMode` is what selects 1.4; see {@link DataFabricReadInputs.resultMode}.
+ *
+ * The native family covers all four CRUD verbs: this one,
+ * {@link dataFabricCreate}, {@link dataFabricUpdate} and
+ * {@link dataFabricDelete}. What it does NOT cover is get-by-id, a query row
+ * limit, file record fields, and entity events — those are operations on the
+ * SAME product reached through its Integration Service connector,
  * `uipath-uipath-dataservice` (the tenant displays it as **UiPath Data
- * Fabric**), which covers every verb including the two here.
- *
- * Taking this node for the one verb that has a native form leaves the rest of
- * the same entity on the connector — two connection bindings and two payload
- * shapes in one flow. So route entity work through the connector unless the
- * scenario names these nodes; native forms for the remaining verbs are the
- * direction of travel, and this guidance changes when they land. `check` does
- * not reject a native node — this is a routing default, not a rule:
+ * Fabric**). So a flow that needs one of those still straddles two surfaces,
+ * and the connector remains the one surface that covers everything:
  *
  * ```ts
- * .step('create', connector('uipath-uipath-dataservice', 'create-entity-record',
- *   { entityName: 'Contracts', contractTitle: 'Q3 renewal' }, { connection: 'df' }))
+ * .step('byId', connector('uipath-uipath-dataservice', 'get-entity-record-by-id',
+ *   { entityName: 'Contracts', recordId: input('id') }, { connection: 'df' }))
  * ```
  *
- * That operation's body fields come from the entity, so the library cannot
- * carry them: run `npx flow-sdk registry prepare uipath-uipath-dataservice
- * create-entity-record -f entityName=<Entity>` first (`uip maestro registry
- * prepare …` is the same command when you are driving through the UiPath CLI). The routing table is in
- * the `data-fabric.md` reference and the parent-field loop in
- * `connector-params.md` — cited by name rather than linked, because this
+ * A connector operation's body fields come from the entity, so the library
+ * cannot carry them: run `uip maestro registry prepare uipath-uipath-dataservice
+ * get-entity-record-by-id -f entityName=<Entity>` first (`npx flow-sdk registry
+ * prepare …` is the same command when invoking the package's own bin directly).
+ * The routing table is in the `data-fabric.md` reference and the parent-field
+ * loop in `connector-params.md` — cited by name rather than linked, because this
  * comment renders both into the flat corpus, where those files sit alongside
  * it, and onto the site, where each symbol is its own page and a relative
  * `./data-fabric` resolves to nothing.
  *
- * @param inputs - The entity, optional filter rows, and folder scope.
+ * @param inputs - The entity, optional filter rows, result mode, and folder scope.
  * @returns An action spec to pass to `.step(name, …)`.
  */
 export function dataFabricRead(inputs) {
     return builtinActionSpec({ kind: 'dataFabricRead', inputs });
 }
+/**
+ * Create an entity record in Data Fabric (`core.datafabric.create`). The new
+ * record publishes to the step's `output`, so a following
+ * {@link dataFabricUpdate} or {@link dataFabricDelete} can read its id.
+ *
+ * @remarks
+ * `values` must name at least one column — the node's schema rejects an empty
+ * field list rather than inserting a blank row, and `check` says so before the
+ * platform does. Field names are the ENTITY's, so copy them from the scenario
+ * or the tenant; nothing offline can tell a real column from a typo.
+ *
+ * See {@link dataFabricRead} for what the native family still does not cover
+ * and which connector operation covers it.
+ *
+ * @param inputs - The entity, the columns the record starts with, and folder scope.
+ * @returns An action spec to pass to `.step(name, …)`.
+ */
+export function dataFabricCreate(inputs) {
+    return builtinActionSpec({ kind: 'dataFabricCreate', inputs });
+}
 /**
  * Update an entity record in Data Fabric (`core.datafabric.update`). Target the
  * record by id or through an earlier {@link dataFabricRead} step; downstream
  * reads of this step observe the record AFTER the write.
  *
  * @remarks
- * The second and last verb of the native family — see {@link dataFabricRead}
- * for what the family does NOT cover, which connector operation covers it
- * instead, and why entity work routes through the connector during the
- * transition. For an update whose flow also creates, gets or deletes on the
- * same entity, use `connector(…, 'update-entity-record', …)` so the flow keeps
- * one surface.
+ * `set` must write at least one column: an empty `set` is a no-op the platform
+ * reports as success, so `check` rejects it.
+ *
+ * See {@link dataFabricRead} for what the native family still does not cover
+ * and which connector operation covers it.
  *
  * @param inputs - The entity, the record selector, and the columns to write.
  * @returns An action spec to pass to `.step(name, …)`.
  */
 export function dataFabricUpdate(inputs) {
-    const byId = inputs.record?.byId !== undefined;
-    const fromRead = typeof inputs.record?.fromRead === 'string';
+    assertOneRecordRef(inputs.record, 'dataFabricUpdate');
+    return builtinActionSpec({ kind: 'dataFabricUpdate', inputs });
+}
+/**
+ * Delete an entity record from Data Fabric (`core.datafabric.delete`). Target
+ * the record by id or through an earlier {@link dataFabricRead} step, exactly
+ * as {@link dataFabricUpdate} does.
+ *
+ * @remarks
+ * A delete **publishes nothing** — its definition declares no output — so
+ * `$vars.<step>.output` is undefined at run time and `check` rejects a read of
+ * it. Take what you need off the read step that found the record, before the
+ * delete.
+ *
+ * See {@link dataFabricRead} for what the native family still does not cover
+ * and which connector operation covers it.
+ *
+ * @param inputs - The entity, the record selector, and folder scope.
+ * @returns An action spec to pass to `.step(name, …)`.
+ */
+export function dataFabricDelete(inputs) {
+    assertOneRecordRef(inputs.record, 'dataFabricDelete');
+    return builtinActionSpec({ kind: 'dataFabricDelete', inputs });
+}
+/**
+ * `record` names exactly ONE of `{ byId }` / `{ fromRead }`. Both forms are
+ * optional properties on the same object type, so TypeScript alone cannot
+ * refuse `{}` — and an empty selector compiles into a write with no target.
+ */
+function assertOneRecordRef(record, factory) {
+    const byId = record?.byId !== undefined;
+    const fromRead = typeof record?.fromRead === 'string';
     if (byId === fromRead) {
-        throw new Error("dataFabricUpdate() targets exactly ONE of record: { byId } or record: { fromRead: '<step>' }.");
+        throw new Error(`${factory}() targets exactly ONE of record: { byId } or record: { fromRead: '<step>' }.`);
     }
-    return builtinActionSpec({ kind: 'dataFabricUpdate', inputs });
 }
 /**
  * Declare an Orchestrator QUEUE ITEM step.