@uipath/maestro-builder-sdk 6.24.0 → 6.25.0

package/dist/core/actions.d.ts

@@ -106,254 +106,6 @@ export interface InOutField {
     required?: boolean;
 }
 export type FormField = ShownField | AskedField | InOutField;
-/**
- * Where the task is delivered. The four ids are the platform's own — including
- * the lowercase `'teams'`, which is how every deployed recipient spells
- * Microsoft Teams (the canvas's channel list, `hitl-types.ts`).
- */
-export type HitlChannel = 'Slack' | 'teams' | 'Email' | 'ActionCenter';
-/**
- * How the task is assigned, the platform's own vocabulary (canvas
- * `HITL_ASSIGNEE_TYPE`): `'user'` a single user, `'group'` all users of a
- * group, `'staticEmail'`/`'staticGroupName'` literal values instead of
- * directory picks, `'workload'`/`'roundRobin'` distribution over a group, and
- * `'custom'` an expression the engine evaluates (`value` holds it).
- */
-export type HitlAssigneeType = 'user' | 'group' | 'staticEmail' | 'staticGroupName' | 'workload' | 'roundRobin' | 'custom';
-/** A per-channel Integration Service connection (Slack / Teams delivery). */
-export interface HitlConnection {
-    /** The connection's display name. */
-    name?: string | null;
-    /** The connection key the engine resolves, e.g. `'Slack'` for the default. */
-    key: string;
-    /** Folder the connection lives in; `null` for tenant-level defaults. */
-    folderPath?: string | null;
-}
-/**
- * Who gets the task and over which channels. Omit the whole object for the
- * definition's default (Email + Action Center, assigned to a group) — which is
- * what 203 of 233 deployed v1 human tasks carry, and what this SDK has always
- * emitted.
- *
- * ```ts
- * hitl({
- *   recipient: {
- *     channels: ['Email', 'ActionCenter'],
- *     assignee: { type: 'user', value: 'reviewer@acme.test' },
- *   },
- *   …
- * })
- * ```
- */
-export interface HitlRecipient {
-    /** Delivery channels. Defaults to the emitted definition's own default set. */
-    channels?: HitlChannel[];
-    /** Who the task is assigned to. */
-    assignee: {
-        type: HitlAssigneeType;
-        /**
-         * The user email / group name / expression, per `type`. The engine lowers
-         * this to its `{ Value, Type }` recipient contract; without one the task
-         * falls back to the tenant's assignment default.
-         */
-        value?: string;
-        /** Display name the designer shows next to the pick. Cosmetic. */
-        displayName?: string;
-    };
-    /**
-     * Per-channel connections, keyed by channel id (`Slack` / `teams`). Only the
-     * connector-backed channels take one; Email and Action Center do not.
-     */
-    connections?: Partial<Record<'Slack' | 'teams', HitlConnection>>;
-}
-/**
- * The Document Validation task's subject — `variant: 'document-validation'`
- * only. The reviewer gets the platform's validation station (or a custom app
- * with a Validation Control) over a document and its extraction result.
- */
-export interface DocValidationInputs {
-    /**
-     * The extraction result to validate — bind the `ExtractionResult` output of
-     * an upstream Extract step, e.g. `out('extract', 'ExtractionResult')`.
-     * Required: the station has nothing to validate without it.
-     */
-    extractionResult: Expr | string;
-    /** Storage bucket id holding the document. */
-    storageBucket?: string;
-    /** The document's id within the bucket. */
-    documentId?: string;
-    /**
-     * `'standard'` (default) for the native validation station, `'custom'` for a
-     * custom app with a Validation Control — which then requires `taxonomy`.
-     */
-    render?: 'standard' | 'custom';
-    /** The taxonomy the custom app validates against. Required when `render: 'custom'`. */
-    taxonomy?: Expr | string;
-}
-/**
- * One completion button. `action: 'End'` marks an outcome that ENDS the process
- * rather than continuing (the platform's own two-value vocabulary — anything
- * that is not exactly `'End'` reads as continue).
- *
- * `id` is the outcome's wire id — `schema.outcomes[].id`, and the `outcome-<id>`
- * port its edge leaves from. Leave it out and the id is a slug of `name`
- * (`'Needs info'` → `needs-info`). Set it only to keep an id a flow already
- * has, as decompile does for a task the designer drew
- * (`{ name: 'Reject', id: 'outcome-1778015958049' }`): merge keeps the
- * original node, so its edges must use that node's ids.
- *
- * @remarks
- * A bare string is shorthand for `{ name }`.
- */
-export type Outcome = string | {
-    name: string;
-    action?: 'Continue' | 'End';
-    id?: string;
-};
-/**
- * WHICH human-task node type to emit. The platform ships three spellings of the
- * same node; two of them resolve on this tenant and are what this option picks.
- *
- * @remarks
- * - **omitted** — `uipath.human-in-the-loop`, the original node, which chooses
- *   the form kind with `inputs.type: 'quick'`. This is the default and it does
- *   not change: it is where the platform's own versioning continues, and 319 of
- *   the corpus's human tasks are on it.
- * - **`'quick-form'`** — `uipath.human-in-the-loop.quick-form`. Same inline form,
- *   but the node TYPE is the "quick" choice, so no `inputs.type` is written
- *   (165 of its 175 deployed instances omit it). Everything you author is
- *   identical; pick it when something downstream keys on the literal type
- *   string, which flow-v1's own task checkers do.
- * - **`'action-app'`** — `uipath.human-in-the-loop.coded-action-app`. The form is
- *   NOT in the flow: it belongs to a deployed Action App, named by `app`. You
- *   still declare `outcomes` (the flow routes on them); you must NOT declare
- *   `fields` (the app owns them) — `check` says so.
- *
- * - **`'document-validation'`** — `uipath.human-in-the-loop.document-validation`.
- *   A validation station over a document + extraction result, named by
- *   `document`. No `fields` (the station is the form); `outcomes` still route.
- *   The definition is BUNDLED from the workbench manifest — the tenant registry
- *   does not serve the family (same availability note as do-while).
- */
-export type HitlVariant = 'quick-form' | 'action-app' | 'document-validation';
-/**
- * A deployed Action App that supplies a human task's form — the `'action-app'`
- * variant's subject.
- *
- * @remarks
- * The names are the platform's own, from flow-v1's app picker: an app is closed
- * by `key` (its GUID) plus the `folderPath` it is deployed in, with `name` the
- * human-readable title. This SDK is offline and never calls the Apps API, so
- * what you write here is what you already know about the app.
- *
- * ```ts
- * hitl({
- *   variant: 'action-app',
- *   app: {
- *     name: 'Expense Review',
- *     key: 'c0ba97df-8a30-4fe0-b4b4-4611a631d77b',
- *     folderPath: 'Shared',
- *     inputs: { 'Expense Amount': out('fetchExpense', 'total') },
- *   },
- *   outcomes: ['Approve', 'Reject'],
- * })
- * ```
- */
-export interface AppRef {
-    /** The app's display title, e.g. `'Expense Review'`. */
-    name: string;
-    /** The app's key (a GUID) — how the platform resolves which app this is. */
-    key: string;
-    /** Fully-qualified folder the app is deployed in, e.g. `'Shared'`. */
-    folderPath: string;
-    /**
-     * The app's stable system name. `null` until the app's first deployment
-     * assigns one, which is why it is optional and why `null` is a legal value
-     * rather than something to omit.
-     */
-    appSystemName?: string | null;
-    /**
-     * What to send the app, keyed by the app's OWN input parameter names — so the
-     * keys are the app author's, spaces and all (`'Invoice Amount'`), not
-     * identifiers of ours. Values are references, e.g. `out('step', 'field')`.
-     *
-     * Emitted as `inputs.appInputBindings`, the map flow-v1's serializer turns
-     * into the task's `HitlTaskArguments`.
-     */
-    inputs?: Record<string, Expr | string>;
-}
-export interface HitlInputs {
-    /**
-     * Which human-task node type to emit. Omit it for today's default — see
-     * {@link HitlVariant}. Omitting it emits exactly what it always has.
-     */
-    variant?: HitlVariant;
-    /**
-     * The deployed Action App that owns this task's form. Required by — and only
-     * legal with — `variant: 'action-app'`.
-     */
-    app?: AppRef;
-    /** Task title the reviewer sees. Defaults to the step's label. */
-    title?: string;
-    /** Action Center priority. Defaults to `'Low'`. */
-    priority?: 'Low' | 'Medium' | 'High';
-    /**
-     * The form, as an array of field descriptors — `direction: 'input'` for a value
-     * the reviewer reads, `'output'` for one they fill in. An array (not a map)
-     * because the ids are yours and order is the order on the form.
-     *
-     * Required for the inline-form variants (the default and `'quick-form'`).
-     * FORBIDDEN with `variant: 'action-app'`, where the form belongs to the
-     * deployed app rather than to the flow — `check` says so both ways.
-     */
-    fields?: FormField[];
-    /**
-     * The completion buttons, e.g. `['Approve', 'Reject']`. At least one, or the
-     * reviewer has no way to complete the task and the flow waits forever. The
-     * first is the primary (default) one. Each outcome is its own exit,
-     * `outcome-<slug>`: the default node and `'quick-form'` never leave on
-     * `completed` once they have outcomes. On the default node MORE THAN ONE
-     * outcome routes per outcome: the first continues the main path and the rest
-     * are routed with `.stepToList('outcome-<slug>', …)`. With `'quick-form'`,
-     * {@link HitlInputs.outcomePorts | outcomePorts}`: false`, an explicit
-     * `{ version }` or one outcome, `.step()` continues EVERY outcome instead.
-     *
-     * Which one they pressed is also `out('<step>', 'Action')` — that is what the
-     * platform's own routing conditions compare against.
-     */
-    outcomes: Outcome[];
-    /** Who gets the task and how. Omit for the definition's default delivery. */
-    recipient?: HitlRecipient;
-    /** Action Center labels, comma-separated (the platform stores one string). */
-    labels?: string;
-    /**
-     * Whether the task ROUTES per outcome. Each outcome has its own exit either
-     * way (`outcome-<id>`, the name slugified: `'Approve'` → `outcome-approve`).
-     *
-     * `true`: the FIRST outcome continues the main path and the others are routed
-     * with `.stepToList('outcome-<id>', …)`, or the run stalls when the reviewer
-     * picks one. The default node with more than one outcome already does this,
-     * on its **1.1** definition unless a `{ version }` pins another; `'quick-form'`
-     * supports it on its one definition. `false`: EVERY outcome continues to the
-     * next step on its own edge — a task that routes the decision as DATA by
-     * reading `out('<step>', 'Action')`; `'quick-form'` does this by default.
-     * `'action-app'` and `'document-validation'` read their outcomes from the app
-     * and leave on their one `completed` exit, so `true` is refused there.
-     */
-    outcomePorts?: boolean;
-    /**
-     * Expose the task's runtime error as a bindable `out('<step>', 'error')`
-     * object (`{ code, message, detail, category, status }`). Selects the node's
-     * **1.2** definition — which also routes per outcome, so this implies
-     * {@link HitlInputs.outcomePorts | outcomePorts}. Default node only.
-     */
-    exposeError?: boolean;
-    /**
-     * The document to validate. Required by — and only legal with —
-     * `variant: 'document-validation'`.
-     */
-    document?: DocValidationInputs;
-}
 /**
  * How a conversational agent gets its turn — the node's own
  * `conversationalAgentSettings` sub-object.
@@ -1700,10 +1452,6 @@ export interface ContextIndexRef {
  * whole body rather than an inputs payload.
  */
 export interface FlowActionSpecs {
-    /** The spec {@link hitl} builds. */
-    hitl: {
-        inputs: HitlInputs;
-    };
     /** The spec {@link rpaWorkflow} builds. */
     rpaWorkflow: {
         inputs: RpaWorkflowInputs;
@@ -1807,58 +1555,6 @@ export declare function builtinActionSpec<S extends object>(spec: S): S;
  * @returns The same spec, as a `FlowTrigger` instance.
  */
 export declare function builtinTriggerSpec<S extends object>(spec: S): S;
-/**
- * Declare a human task — a step that pauses for a person to read some values,
- * fill others in, and press one of the outcome buttons.
- *
- * @remarks
- * Read an answer with `out('review', '<fieldId>')`, and which button they pressed
- * with `out('review', 'Action')` — branch on that for per-outcome routing.
- *
- * ### Picking a node type with `variant`
- *
- * The example above emits `uipath.human-in-the-loop`, the original node, and
- * that stays the default. Two other spellings of the same human task exist
- * ({@link HitlVariant}), and `variant` is how you say which:
- *
- * ```ts
- * // Same inline form, the newer node type — no `inputs.type` is written.
- * hitl({ variant: 'quick-form', fields: […], outcomes: ['Approve', 'Reject'] })
- *
- * // The form lives in a DEPLOYED APP: no `fields`, but still your outcomes.
- * hitl({
- *   variant: 'action-app',
- *   app: { name: 'Expense Review', key: '<guid>', folderPath: 'Shared',
- *          inputs: { 'Expense Amount': out('fetchExpense', 'total') } },
- *   outcomes: ['Approve', 'Reject'],
- * })
- * ```
- *
- * What every variant shares: one `completed` port, and the same two outputs
- * (`output`, carrying the answers, and `status`, carrying the outcome name) —
- * all three definitions declare them identically, so downstream reads do not
- * change when you switch.
- *
- * @example
- * **Pause for a person to approve, then read their decision**
- * ```ts
- * .step('review', hitl({
- *   title: 'Review Expense',
- *   fields: [
- *     { id: 'amount',   type: 'number',  direction: 'input',  value: input('amount') },
- *     { id: 'approved', type: 'boolean', direction: 'output' },
- *     { id: 'comments', type: 'text',    direction: 'output' },
- *   ],
- *   outcomes: ['Approve', 'Reject'],
- * }))
- * .step('log', script({ code: 'return "Decision: " + $vars.review.output.approved;' }))
- * ```
- *
- * @param inputs - The form's fields, outcomes and recipient.
- * @returns An action spec for `.step(...)`.
- * @example example-eval/GallerySubmission.flow.ts
- */
-export declare function hitl(inputs: HitlInputs): ActionSpec;
 /**
  * Extract fields from a document with a published IxP project — the platform's
  * **Extract** node (`uipath.ixp.*`, service contract `IXP.Extraction`).

package/dist/core/actions.js

@@ -88,60 +88,6 @@ export function builtinActionSpec(spec) {
 export function builtinTriggerSpec(spec) {
     return new BuiltinTrigger(spec);
 }
-/**
- * Declare a human task — a step that pauses for a person to read some values,
- * fill others in, and press one of the outcome buttons.
- *
- * @remarks
- * Read an answer with `out('review', '<fieldId>')`, and which button they pressed
- * with `out('review', 'Action')` — branch on that for per-outcome routing.
- *
- * ### Picking a node type with `variant`
- *
- * The example above emits `uipath.human-in-the-loop`, the original node, and
- * that stays the default. Two other spellings of the same human task exist
- * ({@link HitlVariant}), and `variant` is how you say which:
- *
- * ```ts
- * // Same inline form, the newer node type — no `inputs.type` is written.
- * hitl({ variant: 'quick-form', fields: […], outcomes: ['Approve', 'Reject'] })
- *
- * // The form lives in a DEPLOYED APP: no `fields`, but still your outcomes.
- * hitl({
- *   variant: 'action-app',
- *   app: { name: 'Expense Review', key: '<guid>', folderPath: 'Shared',
- *          inputs: { 'Expense Amount': out('fetchExpense', 'total') } },
- *   outcomes: ['Approve', 'Reject'],
- * })
- * ```
- *
- * What every variant shares: one `completed` port, and the same two outputs
- * (`output`, carrying the answers, and `status`, carrying the outcome name) —
- * all three definitions declare them identically, so downstream reads do not
- * change when you switch.
- *
- * @example
- * **Pause for a person to approve, then read their decision**
- * ```ts
- * .step('review', hitl({
- *   title: 'Review Expense',
- *   fields: [
- *     { id: 'amount',   type: 'number',  direction: 'input',  value: input('amount') },
- *     { id: 'approved', type: 'boolean', direction: 'output' },
- *     { id: 'comments', type: 'text',    direction: 'output' },
- *   ],
- *   outcomes: ['Approve', 'Reject'],
- * }))
- * .step('log', script({ code: 'return "Decision: " + $vars.review.output.approved;' }))
- * ```
- *
- * @param inputs - The form's fields, outcomes and recipient.
- * @returns An action spec for `.step(...)`.
- * @example example-eval/GallerySubmission.flow.ts
- */
-export function hitl(inputs) {
-    return builtinActionSpec({ kind: 'hitl', inputs });
-}
 /**
  * Extract fields from a document with a published IxP project — the platform's
  * **Extract** node (`uipath.ixp.*`, service contract `IXP.Extraction`).

package/dist/core/form-field-type.d.ts

@@ -31,3 +31,19 @@ import type { FormFieldType } from './actions.js';
  * sdkFormFieldType('integer')  // undefined
  */
 export declare function sdkFormFieldType(wire: unknown): FormFieldType | undefined;
+/**
+ * Why a form-field type is refused: a product spelling of a type the SDK
+ * models (`"string"` is the platform's own name for text), or a type
+ * the SDK does not model at all. `unknownWhy` is the caller's reason for the
+ * second case; the default is a human task's.
+ */
+export declare function formFieldTypeWhy(type: unknown, unknownWhy?: string): string;
+/** The form-field types the SDK models. */
+export declare const FORM_FIELD_TYPES: string[];
+/** The `suggestion` for an unknown form-field type: the nearest valid one, else `type: 'text'`. */
+export declare function formFieldTypeHint(type: unknown): string;
+/** JSON-Schema type per form-field type, as flow-v1's form serializer maps them (quick-form escalations and human tasks). */
+export declare const FORM_FIELD_JSON_TYPE: Record<FormFieldType, {
+    type: string;
+    format?: string;
+}>;

package/dist/core/form-field-type.js

@@ -1,3 +1,4 @@
+import { nearestName } from './edit-distance.js';
 const PRODUCT_SPELLINGS = {
     text: 'text',
     string: 'text',
@@ -28,3 +29,35 @@ const PRODUCT_SPELLINGS = {
 export function sdkFormFieldType(wire) {
     return typeof wire === 'string' && Object.hasOwn(PRODUCT_SPELLINGS, wire) ? PRODUCT_SPELLINGS[wire] : undefined;
 }
+/**
+ * Why a form-field type is refused: a product spelling of a type the SDK
+ * models (`"string"` is the platform's own name for text), or a type
+ * the SDK does not model at all. `unknownWhy` is the caller's reason for the
+ * second case; the default is a human task's.
+ */
+export function formFieldTypeWhy(type, unknownWhy = `which the platform does not recognize. Older runtimes read it as text, newer ones reject `
+    + `the form`) {
+    const alias = sdkFormFieldType(type);
+    return alias !== undefined
+        ? `which is the platform's spelling of the SDK's '${alias}' — the SDK writes '${alias}'`
+        : unknownWhy;
+}
+/** Every FormFieldType, once; `Record<FormFieldType, …>` makes tsc refuse a missing or extra one. */
+const FORM_FIELD_TYPE_SET = { text: true, number: true, boolean: true, 'date-time': true };
+/** The form-field types the SDK models. */
+export const FORM_FIELD_TYPES = Object.keys(FORM_FIELD_TYPE_SET);
+/** The `suggestion` for an unknown form-field type: the nearest valid one, else `type: 'text'`. */
+export function formFieldTypeHint(type) {
+    const alias = sdkFormFieldType(type);
+    if (alias !== undefined)
+        return `type: '${alias}'`;
+    const nearest = nearestName(String(type), FORM_FIELD_TYPES);
+    return nearest !== undefined ? `type: '${nearest}'` : `type: 'text'`;
+}
+/** JSON-Schema type per form-field type, as flow-v1's form serializer maps them (quick-form escalations and human tasks). */
+export const FORM_FIELD_JSON_TYPE = {
+    text: { type: 'string' },
+    number: { type: 'number' },
+    boolean: { type: 'boolean' },
+    'date-time': { type: 'string', format: 'date-time' },
+};

package/dist/core/hitl-routing.d.ts

@@ -69,7 +69,21 @@
  * type, including the two app-backed variants, so that `serialize` and `check`
  * refuse them there with their own message rather than silently ignoring them.
  */
-import type { HitlInputs } from './actions.js';
+/**
+ * The fields of a human task's inputs the routing model reads — structural, so
+ * this module stays in `core/` while the authoring type (`HitlInputs`) belongs
+ * to the HITL family (nodes/hitl/flow/).
+ */
+export interface HitlRoutingInputs {
+    readonly variant?: unknown;
+    readonly outcomes?: ReadonlyArray<string | {
+        readonly name?: unknown;
+        readonly action?: unknown;
+        readonly id?: unknown;
+    }>;
+    readonly outcomePorts?: boolean;
+    readonly exposeError?: boolean;
+}
 /**
  * An outcome's stable id — the slug that names its `outcome-<id>` port.
  *
@@ -117,9 +131,9 @@ export type HitlExitModel = {
 export declare const OUTCOME_HANDLE_NODE_TYPES: ReadonlySet<string>;
 /** The same test on the authored side: no variant (the base node), or quick-form. */
 export declare function hitlDerivesOutcomeHandles(variant: unknown): boolean;
-export declare function hitlExitModel(inputs: HitlInputs | undefined, pinnedVersion?: string): HitlExitModel;
+export declare function hitlExitModel(inputs: HitlRoutingInputs | undefined, pinnedVersion?: string): HitlExitModel;
 /** Does this task route PER OUTCOME (primary continues, the rest are routed)? */
-export declare function hitlRoutesPerOutcome(inputs: HitlInputs | undefined, pinnedVersion?: string): boolean;
+export declare function hitlRoutesPerOutcome(inputs: HitlRoutingInputs | undefined, pinnedVersion?: string): boolean;
 type NodeLike = {
     id?: unknown;
     type?: unknown;

package/dist/core/stable-id.d.ts

@@ -59,3 +59,12 @@ export declare function fnv1aX4Uuid(seed: string): string;
  * Consumer: a Case entry point's `uniqueId` in `entry-points.json` (`case/compile-cli.ts`).
  */
 export declare function sha256Uuid(seed: string): string;
+/**
+ * A deterministic UUID for the form schema, derived from the flow and node ids.
+ *
+ * The platform uses `schemaId` to identify and cache a form, so it has to be
+ * stable across builds of the same flow — a random one would make every rebuild a
+ * different form and every emitted `.flow` a different file. Shaped as a v5 UUID
+ * (SHA-1 based, version + variant bits set) because that is what the field holds.
+ */
+export declare function schemaId(flowId: string, nodeId: string): string;

package/dist/core/stable-id.js

@@ -91,3 +91,19 @@ export function sha256Uuid(seed) {
     const h = createHash('sha256').update(seed).digest('hex');
     return `${h.slice(0, 8)}-${h.slice(8, 12)}-${h.slice(12, 16)}-${h.slice(16, 20)}-${h.slice(20, 32)}`;
 }
+/**
+ * A deterministic UUID for the form schema, derived from the flow and node ids.
+ *
+ * The platform uses `schemaId` to identify and cache a form, so it has to be
+ * stable across builds of the same flow — a random one would make every rebuild a
+ * different form and every emitted `.flow` a different file. Shaped as a v5 UUID
+ * (SHA-1 based, version + variant bits set) because that is what the field holds.
+ */
+export function schemaId(flowId, nodeId) {
+    const h = createHash('sha1').update(`uipath.human-in-the-loop:${flowId}:${nodeId}`).digest();
+    const b = Buffer.from(h.subarray(0, 16));
+    b[6] = (b[6] & 0x0f) | 0x50;
+    b[8] = (b[8] & 0x3f) | 0x80;
+    const hex = b.toString('hex');
+    return `${hex.slice(0, 8)}-${hex.slice(8, 12)}-${hex.slice(12, 16)}-${hex.slice(16, 20)}-${hex.slice(20)}`;
+}

package/dist/core/step-ports.d.ts

@@ -1,3 +1,27 @@
+/**
+ * The exits an action declares that the AUTHOR named — a human task's outcomes,
+ * an HTTP call's response branches — and the port each one leaves on. Every
+ * family that has them is a registered node type and declares its own
+ * (`FlowNodeType.exits`); `stepExits` in flow-step-exits.ts asks it first, and
+ * what is left here is the reason a kind has none.
+ *
+ * This is what `.stepSwitch()` routes over, and the reason it exists as a table
+ * rather than as more `if (spec.kind === …)` arms: `serialize` has to turn
+ * an arm's `value` into a port, `check` has to say which values are legal and
+ * which were left out, and `decompile` has to turn a port back into a value.
+ * Those three read the same list instead of each carrying their own copy of
+ * "how a human task names its ports".
+ *
+ * `undefined` means the family has no author-declared fan-out at all, which is
+ * what makes `.stepSwitch()` on it an error rather than a no-op.
+ *
+ * The `error` port is deliberately NOT here. It is declared by the definition
+ * rather than by the author, it exists on families that have no other fan-out,
+ * and it is already routed by `.onError()` / `.stepToList('error', …)`. Folding
+ * it in would make every action a `.stepSwitch` candidate and would put failure
+ * handling and outcome routing in one list, where an omitted arm would mean two
+ * different things.
+ */
 /** One author-named exit: the value an arm matches on, and the port it wires. */
 export interface DeclaredExit {
     /** What `.stepSwitch()`'s arm `value` matches — the outcome or branch NAME. */
@@ -31,7 +55,7 @@ type SpecLike = {
  * The author-declared exits of `spec`, or a `NoExits` explaining why there are
  * none to route.
  */
-export declare function declaredExits(spec: SpecLike | undefined, pinnedVersion?: string): DeclaredExit[] | NoExits;
+export declare function declaredExits(spec: SpecLike | undefined, _pinnedVersion?: string): DeclaredExit[] | NoExits;
 /** Narrowing helper — `declaredExits` returns one or the other. */
 export declare function hasExits(r: DeclaredExit[] | NoExits): r is DeclaredExit[];
 export {};

package/dist/core/step-ports.js

@@ -1,8 +1,9 @@
 /**
- * The exits an action declares that the AUTHOR named — a human task's outcomes —
- * and the port each one leaves on. A registered node type declares its own
- * (`FlowNodeType.exits`: an HTTP call's response branches); `stepExits` in
- * flow-step-exits.ts asks it first and falls back here.
+ * The exits an action declares that the AUTHOR named — a human task's outcomes,
+ * an HTTP call's response branches — and the port each one leaves on. Every
+ * family that has them is a registered node type and declares its own
+ * (`FlowNodeType.exits`); `stepExits` in flow-step-exits.ts asks it first, and
+ * what is left here is the reason a kind has none.
  *
  * This is what `.stepSwitch()` routes over, and the reason it exists as a table
  * rather than as more `if (spec.kind === …)` arms: `serialize` has to turn
@@ -21,54 +22,12 @@
  * handling and outcome routing in one list, where an omitted arm would mean two
  * different things.
  */
-import { hitlExitModel } from './hitl-routing.js';
 /**
  * The author-declared exits of `spec`, or a `NoExits` explaining why there are
  * none to route.
  */
-export function declaredExits(spec, pinnedVersion) {
+export function declaredExits(spec, _pinnedVersion) {
     const kind = spec && 'kind' in spec ? spec.kind : undefined;
-    if (kind === 'hitl') {
-        const inputs = spec?.inputs;
-        const model = hitlExitModel(inputs, pinnedVersion);
-        if (model.shape === 'placeholder') {
-            // WHY it has no outcome exits decides what the author can do about it, so
-            // the caller gets the specific one rather than "ports are off".
-            if ((inputs?.outcomes ?? []).length === 0) {
-                return { reason: 'it declares no outcomes', suggestion: `outcomes: ['Approve', 'Reject']` };
-            }
-            return {
-                reason: `the '${inputs?.variant}' variant reads its outcomes from its app and leaves on its single 'completed' exit`,
-                suggestion: `Use .step() and switch on out('<step>', 'Action').`,
-            };
-        }
-        // A quick-form task and a pinned one continue every outcome under `.step()`,
-        // but their outcome handles are real, so `.stepSwitch` routes them. The
-        // other fan-out reasons leave nothing to route.
-        if (model.shape === 'every-outcome' && model.why !== 'quick-form' && model.why !== 'pinned') {
-            if (model.why === 'outcomePorts: false') {
-                return {
-                    reason: 'outcomePorts: false continues every outcome to the next step',
-                    suggestion: 'Drop `outcomePorts: false`.',
-                };
-            }
-            if (model.why === 'one outcome') {
-                return {
-                    reason: 'a single outcome has a single exit, so there is nothing to route',
-                    suggestion: 'Use .step() — the next step follows it unconditionally.',
-                };
-            }
-            return {
-                reason: 'every outcome ends the process, so no exit distinguishes them',
-                suggestion: 'Use .step().',
-            };
-        }
-        return model.exits.map((e) => ({
-            value: e.value,
-            port: e.port,
-            ...(e.endsProcess ? { endsProcess: true } : {}),
-        }));
-    }
     return {
         reason: `a ${kind ?? 'custom'} step declares no author-named exits`,
         suggestion: 'Use .step(); route failures with .onError().',

package/dist/core/typed-raw-node.js

@@ -34,14 +34,6 @@ export const TYPED_FACTORIES = {
     'uipath.agent.voice': { factory: 'voiceAgent()' },
     'uipath.conversational.voice.create-outgoing-call': { factory: 'createOutgoingCall()' },
     'uipath.conversational.voice.end-call': { factory: 'endCall()' },
-    'uipath.human-in-the-loop': { factory: 'hitl()' },
-    'uipath.human-in-the-loop.coded-action-app': {
-        factory: "hitl({ variant: 'action-app' })",
-    },
-    'uipath.human-in-the-loop.document-validation': {
-        factory: "hitl({ variant: 'document-validation' })",
-    },
-    'uipath.human-in-the-loop.quick-form': { factory: "hitl({ variant: 'quick-form' })" },
 };
 /**
  * A reminder, as a `warning`, that a `rawNode` stands in for a typed factory,