@zeniai/web-components 4.1.67-betaJK1 → 4.1.68

package/dist/components/common/zeniDatePicker/ZeniDatePickerField.d.ts

@@ -13,9 +13,8 @@ export interface Props {
     dateFormat?: string;
     inputStyles?: InputStyles;
     minDate?: ZeniDate;
-    placeHolder?: JSX.Element;
     registerOptions?: RegisterOptions;
     style?: React.CSSProperties;
 }
-declare const ZeniDatePickerField: ({ name, defaultValue, registerOptions, dateFormat, style, inputStyles, minDate, placeHolder, }: Props) => import("react/jsx-runtime").JSX.Element;
+declare const ZeniDatePickerField: ({ name, defaultValue, registerOptions, dateFormat, style, inputStyles, minDate, }: Props) => import("react/jsx-runtime").JSX.Element;
 export default ZeniDatePickerField;

package/dist/components/commonSetUp/approval/AmountConditionRow.d.ts

@@ -0,0 +1,21 @@
+/**
+ * Form-state keys used by the amount-condition group.
+ *
+ * The row is a composite: a comparator picker + one or two amount inputs.
+ * All three pieces nest under the single form key `amountCriteria` so the
+ * connector can read `formData.amountCriteria` as a complete
+ * `AmountCriteria` value at save time.
+ */
+export declare const AMOUNT_CRITERIA_FIELD = "amountCriteria";
+export declare const AMOUNT_COMPARATOR_FIELD = "amountCriteria.comparator";
+export declare const AMOUNT_MIN_FIELD = "amountCriteria.min.amount";
+export declare const AMOUNT_MAX_FIELD = "amountCriteria.max.amount";
+export interface AmountConditionRowProps {
+    /**
+     * Currency symbol surfaced as a placeholder prefix on every amount input.
+     * Defaults to `"$"` when the rule has no stored currency yet.
+     */
+    currencySymbol?: string;
+}
+export declare function AmountConditionRow({ currencySymbol, }: AmountConditionRowProps): import("react/jsx-runtime").JSX.Element;
+export default AmountConditionRow;

package/dist/components/commonSetUp/approval/ApprovalRuleSection.d.ts

@@ -1,14 +1,81 @@
 import { BillPayApprovalRuleWithUser, RemiApprovalRuleWithUser } from '@zeniai/client-epic-state';
+/**
+ * The setup-approver view selectors alias the same underlying
+ * `ApprovalRuleWithUser` shape across bills and reimbursements.
+ */
+export type ApprovalRuleWithUser = BillPayApprovalRuleWithUser | RemiApprovalRuleWithUser;
 export interface DialogAction {
     onCancelClick: () => void;
     onOkClick: (notes?: string) => void;
 }
-declare const ApprovalRuleSection: ({ showDeleteBtn, disableButtons, isLastSection, approvalRule, onEditRuleClick, onDeleteRuleClick, }: {
-    approvalRule: BillPayApprovalRuleWithUser | RemiApprovalRuleWithUser;
+/**
+ * react-dnd item shape carried while dragging a rule card. Carries
+ * the source rule's id so the drop target can issue an
+ * 'onReorder(sourceId, targetId)' callback to the parent on release.
+ */
+export interface RuleDragItem {
+    ruleId: string;
+}
+/** react-dnd type discriminator for approval-rule cards. */
+export declare const APPROVAL_RULE_DND_TYPE = "approval-rule";
+export interface Props {
+    approvalRule: ApprovalRuleWithUser;
     isLastSection: boolean;
     showDeleteBtn: boolean;
+    /**
+     * Optional department-id → display-name map. In this codebase
+     * "department" maps to the Class entity (accounting class); the list
+     * page derives this from `state.classState`.
+     */
+    departmentNamesById?: Record<string, string>;
     disableButtons?: boolean;
+    /**
+     * Number rendered before the rule name (e.g. "1. Marketing vendor block").
+     * Defaults to `approvalRule.priority`.
+     */
+    positionNumber?: number;
+    /**
+     * Optional vendor-id → display-name map. The list page derives this
+     * from `state.contactState` (vendors are stored as contacts). Chips
+     * fall back to the raw ID when no entry is found.
+     */
+    vendorNamesById?: Record<string, string>;
     onDeleteRuleClick: (ruleId: string) => void;
     onEditRuleClick: (ruleId?: string) => void;
-}) => import("react/jsx-runtime").JSX.Element;
+    /**
+     * Called when the user drops THIS card (drop target) after dragging
+     * another rule onto it. Receives the source and target rule ids;
+     * the list page composes the new order and dispatches the reorder
+     * action. Optional — when omitted the card renders without a drag
+     * handle and is not draggable.
+     */
+    onReorderRules?: (dragRuleId: string, hoverRuleId: string) => void;
+}
+/**
+ * Approval rule list-page card per Approval Rules 3.0:
+ *
+ *   ┌─────────────────────────────────────────────────────────┐
+ *   │ 1. Marketing vendor block        [Separation of Duties] ⋮│
+ *   │ All marketing bills route through department lead       │
+ *   │ When: [Amount > $1,000] [Department is Sales & Mktg]    │
+ *   │ Then: 1. Require approval from Jordan Leo or Elena King │
+ *   │       2. Require approval from Matteo Ramsey            │
+ *   └─────────────────────────────────────────────────────────┘
+ *
+ * Accepts the entity-shape `ApprovalRuleWithUser` (steps have resolved
+ * User objects, criteria is the discriminated union). The parent
+ * provides optional `vendorNamesById` / `departmentNamesById` so chips
+ * render names instead of raw IDs.
+ *
+ * The kebab now opens an internal dropdown (Edit / Delete for V1; Pause
+ * and Activity to follow once their action wiring exists). Edit dispatches
+ * `onEditRuleClick(approvalRuleId)`; Delete opens the legacy delete-
+ * confirmation popup which then dispatches `onDeleteRuleClick(approvalRuleId)`.
+ *
+ * `showDeleteBtn` is accepted for backward compat with the existing list
+ * pages but no longer drives any UI — the kebab and its menu items are
+ * always rendered (subject to `disableButtons` for the in-flight pusher
+ * case). Once callers stop passing it, the prop can be removed.
+ */
+declare const ApprovalRuleSection: ({ approvalRule, isLastSection, disableButtons, onDeleteRuleClick, onEditRuleClick, vendorNamesById, departmentNamesById, positionNumber, onReorderRules, }: Props) => import("react/jsx-runtime").JSX.Element;
 export default ApprovalRuleSection;

package/dist/components/commonSetUp/approval/ApprovalRuleSectionV1.d.ts

@@ -0,0 +1,14 @@
+import { BillPayApprovalRuleWithUser, RemiApprovalRuleWithUser } from '@zeniai/client-epic-state';
+export interface DialogAction {
+    onCancelClick: () => void;
+    onOkClick: (notes?: string) => void;
+}
+declare const ApprovalRuleSection: ({ showDeleteBtn, disableButtons, isLastSection, approvalRule, onEditRuleClick, onDeleteRuleClick, }: {
+    approvalRule: BillPayApprovalRuleWithUser | RemiApprovalRuleWithUser;
+    isLastSection: boolean;
+    showDeleteBtn: boolean;
+    disableButtons?: boolean;
+    onDeleteRuleClick: (ruleId: string) => void;
+    onEditRuleClick: (ruleId?: string) => void;
+}) => import("react/jsx-runtime").JSX.Element;
+export default ApprovalRuleSection;

package/dist/components/commonSetUp/approval/ApprovalStageRow.d.ts

@@ -0,0 +1,121 @@
+import { ApprovalActionType, AttributeType, User } from '@zeniai/client-epic-state';
+/**
+ * Approval Rules 3.0 — Set Approval Stages row.
+ *
+ * One stage in the rule's sequential approval pipeline, laid out as:
+ *
+ *   [::] [N.] [Require | Notify] [Actor kind ▾] [Value picker] [🗑]
+ *
+ * Actor kind drives the value picker:
+ *   - "specific_person" → user multi-select (renders avatars + "or"
+ *     between names, via the existing `UserMultiSelectField`).
+ *   - "role" → single-select of `Manager / Manager of Manager /
+ *     Vendor Owner`, backed by `AttributeType` in `client-epic-state`.
+ *
+ * Form-state model — each row binds to a slot under `steps[N]`:
+ *   - `steps[N].action`         → 'require_approval' | 'send_notification'
+ *   - `steps[N].actorKind`      → 'specific_person' | 'role'
+ *   - `steps[N].persons`        → `{allUsers, allNonUsers, selectedUsers, selectedNonUsers}`
+ *                                 (the UserMultiSelectField-native shape)
+ *   - `steps[N].selectedRole`   → AttributeType | undefined
+ *
+ * Both `persons` and `selectedRole` live on the slot at all times so
+ * the user can toggle actor kind without losing the data they entered
+ * for the other variant. The screen connector reads the relevant
+ * branch based on `actorKind` at save time and ignores the other.
+ *
+ * Drag handle is wired up to 'react-dnd' (HTML5 backend, configured
+ * by the enclosing ApprovalStagesSection's DndProvider). The handle
+ * is the drag source; the whole row is the drop target with the
+ * standard hover-middle gate so a drag past the row's vertical center
+ * triggers reorder. The parent owns the reorder via the
+ * 'onReorder(dragIndex, hoverIndex)' callback — the row never mutates
+ * form state directly. See ApprovalsActivity / RealTimeApprovalListItem
+ * for the canonical pattern this mirrors.
+ */
+/**
+ * react-dnd item shape carried while dragging a stage row. Index is
+ * mutated in-place during hover (per the react-dnd reorder pattern)
+ * so subsequent hovers see the rebased index without re-querying the
+ * monitor.
+ */
+export interface StageDragItem {
+    index: number;
+}
+/** react-dnd type discriminator for stage rows. */
+export declare const STAGE_DND_TYPE = "approval-stage";
+/** The two actor-kind variants the row's type dropdown surfaces. */
+export type ApprovalStageActorKind = "specific_person" | "role";
+/**
+ * Form-state shape for a single stage row. Lives on
+ * `FormData.steps[N]` in the BillPay and Reimbursement detail pages.
+ *
+ * `persons` and `selectedRole` both live on every stage so the user
+ * can toggle actor kind without losing data they entered for the
+ * other variant. The screen connector reads only the branch that
+ * matches `actorKind` at save time.
+ */
+export interface ApprovalStageData {
+    /** Sequential index within the stage list. Re-numbered on add/remove. */
+    stageIndex: number;
+    /**
+     * Require / Notify segmented toggle binding. Bare string because
+     * the toggle uses a plain `Controller` (not `SingleSelectField`).
+     */
+    action?: ApprovalActionType;
+    /**
+     * Drives the value picker variant. Wrapped because the dropdown is
+     * `SingleSelectField`-driven (writes `{allOptions, selectedOption}`).
+     * Readers do `actorKind.selectedOption`.
+     */
+    actorKind?: {
+        allOptions: ApprovalStageActorKind[];
+        selectedOption?: ApprovalStageActorKind;
+    };
+    /**
+     * Bound when `actorKind.selectedOption === "specific_person"`.
+     * Shape matches `UserMultiSelectField`'s native value so the field
+     * can re-use existing avatar rendering and "or" join.
+     */
+    persons?: {
+        allNonUsers: any[];
+        allUsers: any[];
+        selectedNonUsers: any[];
+        selectedUsers: any[];
+    };
+    /**
+     * Bound when `actorKind.selectedOption === "role"`. Wrapped shape
+     * (same reason as actorKind). Readers do `selectedRole.selectedOption`.
+     */
+    selectedRole?: {
+        allOptions: AttributeType[];
+        selectedOption?: AttributeType;
+    };
+}
+export interface ApprovalStageRowProps {
+    /** Pool of users surfaced by the "Specific Person" multi-select. */
+    allUsers: User[];
+    /** When `false`, the trash icon is dimmed and inert. */
+    canRemove: boolean;
+    /**
+     * Base react-hook-form path for this row (e.g. `"steps.0"`). Inner
+     * controls suffix `.action`, `.actorKind`, `.persons`,
+     * `.selectedRole` as needed. The shape mirrors `ApprovalStageData`
+     * defined alongside the parent section.
+     */
+    fieldNameBase: string;
+    /** Zero-based index of this row within the parent's stage list. */
+    index: number;
+    /** Called when the user clicks the trash icon. */
+    onRemove: () => void;
+    /**
+     * Called continuously while the user drags one stage over another,
+     * once the cursor crosses the hover target's vertical midpoint.
+     * Optional — when omitted the row is rendered as inert (no drag
+     * handlers attached). The parent owns the reorder mutation; this
+     * callback receives the two indices to swap.
+     */
+    onReorder?: (dragIndex: number, hoverIndex: number) => void;
+}
+export declare function ApprovalStageRow({ index, fieldNameBase, allUsers, onRemove, canRemove, onReorder, }: ApprovalStageRowProps): import("react/jsx-runtime").JSX.Element;
+export default ApprovalStageRow;

package/dist/components/commonSetUp/approval/ApprovalStagesSection.d.ts

@@ -0,0 +1,66 @@
+import { User } from '@zeniai/client-epic-state';
+/**
+ * Approval Rules 3.0 — Set Approval Stages form section.
+ *
+ * Renders the third FormSection of the rule create/edit form. Holds:
+ *
+ *   ┌────────────────────────────────────────────────────────────┐
+ *   │ 1. [Require|Notify] [Specific Person ▾] [users…] [🗑]      │
+ *   │ 2. [Require|Notify] [Role ▾]            [Manager  ▾] [🗑]  │
+ *   │ Clear All                          ⊕ Add Approval Stage   │
+ *   │ ─────────────────────────────────────────────────────────  │
+ *   │ Separation of Duties                                   ⏺  │
+ *   │ Enabling separation of duties prevent ...                  │
+ *   └────────────────────────────────────────────────────────────┘
+ *
+ * Stage rows are owned by `formData.steps`. The component reads the
+ * list length from form state via `useWatch` indirectly through the
+ * stagesValue prop, and lets the parent own the add / remove / clear
+ * actions (mirroring the ConditionRow pattern). The parent is also
+ * responsible for translating the form-data shape to canonical
+ * `Step[]` at save time in the screen connector.
+ *
+ * The Separation of Duties toggle sits inside the same FormSection
+ * card per product spec — SoD is a stage-modifier, so visually it
+ * belongs with the stages it modifies.
+ */
+export interface ApprovalStagesSectionProps {
+    /**
+     * Pool of users surfaced inside the "Specific Person" multi-select
+     * on each row. Resolved by the parent — in production, this is the
+     * tenant's filtered approver list.
+     */
+    allUsers: User[];
+    /** Form-state key for the SoD boolean toggle. */
+    separationOfDutiesFieldName: string;
+    /**
+     * Stage 'fields' produced by 'useFieldArray' in the parent. Each
+     * carries a stable 'id' the section uses as the React key so React
+     * physically reorders DOM nodes on drag-drop — which in turn
+     * forces each row's 'index' / 'fieldNameBase' props to update and
+     * its Controllers to re-bind to the new form-state paths. Keying
+     * by index instead silently broke drag-and-drop because the
+     * positionally-keyed rows kept stale Controller bindings.
+     */
+    stageFields: ReadonlyArray<{
+        id: string;
+    }>;
+    /**
+     * Form-state key prefix for stage rows — typically `"steps"`. Each
+     * row's full path is `${stagesFieldName}.${index}`.
+     */
+    stagesFieldName: string;
+    onAddStage: () => void;
+    onClearAllStages: () => void;
+    onRemoveStage: (index: number) => void;
+    /**
+     * Called when the user drops a dragged stage row onto another row.
+     * The parent re-orders the form-state 'steps' array so the new
+     * order propagates to the save payload via the existing
+     * 'createSteps' iteration. Optional — when omitted the rows render
+     * without drag handlers attached (handle stays visible but inert).
+     */
+    onReorderStages?: (dragIndex: number, hoverIndex: number) => void;
+}
+export declare function ApprovalStagesSection({ allUsers, stageFields, stagesFieldName, separationOfDutiesFieldName, onAddStage, onClearAllStages, onRemoveStage, onReorderStages, }: ApprovalStagesSectionProps): import("react/jsx-runtime").JSX.Element;
+export default ApprovalStagesSection;

package/dist/components/commonSetUp/approval/ConditionRow.d.ts

@@ -0,0 +1,78 @@
+import { ConditionType } from '@zeniai/client-epic-state';
+/**
+ * `ConditionType` is re-exported here so existing import sites in
+ * `web-components` (BillPay + Reimbursement detail pages, stories)
+ * keep working unchanged. The canonical definition lives in
+ * `client-epic-state` (derived from `Criteria["type"]`) so the UI
+ * discriminator can't drift from the data model.
+ */
+export type { ConditionType };
+/**
+ * Approval Rules 3.0 — unified condition row.
+ *
+ * A single row in the Set Conditions section, laid out as one
+ * horizontal line:
+ *
+ *   [ Type ▾ ] [ Operator/Comparator ] [ Value(s) ] [ 🗑 ]
+ *
+ * For Amount: operator slot holds the comparator dropdown
+ * (Greater than / Less than / Between), and the value slot is one
+ * number input (or two for "Between"). For Vendor / Department: the
+ * operator slot is a segmented `is` / `is not` toggle, and the value
+ * slot is a multi-select of vendor or department names.
+ *
+ * Form-state model — controls bind directly to the existing form
+ * paths used by the (now-deprecated for screen use) per-variant rows:
+ *   - `amountCriteria.comparator`, `amountCriteria.min.amount`,
+ *     `amountCriteria.max.amount`
+ *   - `vendorCriteria.operator`, `vendorCriteria.selection`
+ *   - `departmentCriteria.operator`, `departmentCriteria.selection`
+ *
+ * The "list of conditions" is a *visual* construct owned by the
+ * parent: it tracks the ordered list of active types and renders one
+ * ConditionRow per type. When a row is removed the parent clears the
+ * relevant form slot so the payload mapper drops the condition. The
+ * leading type dropdown is parent-controlled (not bound to
+ * react-hook-form) because that list is the source of truth.
+ *
+ * Per task #11 (clear-all UX): the Amount row is non-removable. Its
+ * trash icon is rendered but visually dimmed and disabled so the row
+ * keeps its horizontal alignment with removable rows.
+ *
+ * Visual polish (this iteration):
+ *   1. Each control sits inside a `ControlCard` styled wrapper that
+ *      paints the design-system border + background so the raw
+ *      react-select primitives don't expose their default UA outlines.
+ *   2. The `is` / `is_not` operator is a binary segmented toggle
+ *      (built inline below) rather than a dropdown, matching the
+ *      target design.
+ *   3. The multi-select primitive keeps its built-in
+ *      focused → chips / blurred → comma-text rendering — changing
+ *      that requires modifying the shared `MultiSelectField`, which
+ *      every other consumer depends on. Flagged as a follow-up.
+ */
+export interface ConditionRowProps {
+    availableTypes: readonly ConditionType[];
+    /** When `false`, the trash icon is dimmed and inert. */
+    canRemove: boolean;
+    index: number;
+    rowType: ConditionType;
+    /**
+     * Types currently used by *other* rows (i.e. excludes this row's own
+     * type). They are filtered out of the dropdown so the user can't
+     * create duplicates.
+     */
+    usedTypes: ReadonlySet<ConditionType>;
+    /** Department multi-select options + label lookup. */
+    allDepartmentIds?: string[];
+    /** Vendor multi-select options + label lookup. */
+    allVendorIds?: string[];
+    /** Forwarded to the amount value input when `rowType === "amount"`. */
+    currencySymbol?: string;
+    departmentNamesById?: Record<string, string>;
+    vendorNamesById?: Record<string, string>;
+    onRemove: () => void;
+    onTypeChange: (next: ConditionType) => void;
+}
+export declare function ConditionRow({ rowType, index, availableTypes, usedTypes, onTypeChange, onRemove, canRemove, currencySymbol, allVendorIds, vendorNamesById, allDepartmentIds, departmentNamesById, }: ConditionRowProps): import("react/jsx-runtime").JSX.Element;
+export default ConditionRow;

package/dist/components/commonSetUp/approval/DepartmentConditionRow.d.ts

@@ -0,0 +1,22 @@
+/**
+ * Form-state keys used by the department condition group.
+ *
+ * The form-side split (operator + selection multi-select) mirrors
+ * VendorConditionRow. The screen connector reads
+ * `selection.selectedOptions` and translates to the canonical
+ * `DepartmentCriteria.departmentIds` at save time.
+ */
+export declare const DEPARTMENT_CRITERIA_FIELD = "departmentCriteria";
+export declare const DEPARTMENT_OPERATOR_FIELD = "departmentCriteria.operator";
+export declare const DEPARTMENT_SELECTION_FIELD = "departmentCriteria.selection";
+export interface DepartmentConditionRowProps {
+    /**
+     * All department IDs the user can choose from. Display names are
+     * resolved via `departmentNamesById`. In this codebase "department"
+     * maps to the Class entity, so this is `classId` for each Class.
+     */
+    allDepartmentIds: string[];
+    departmentNamesById: Record<string, string>;
+}
+export declare function DepartmentConditionRow({ allDepartmentIds, departmentNamesById, }: DepartmentConditionRowProps): import("react/jsx-runtime").JSX.Element;
+export default DepartmentConditionRow;

package/dist/components/commonSetUp/approval/FallbackEngineBanner.d.ts

@@ -0,0 +1,28 @@
+import { BillPayApprovalRuleWithUser, RemiApprovalRuleWithUser } from '@zeniai/client-epic-state';
+/**
+ * Shared shape across the two product-specific selectors. Same alias used
+ * in ApprovalRuleSection.
+ */
+export type ApprovalRuleWithUser = BillPayApprovalRuleWithUser | RemiApprovalRuleWithUser;
+export interface FallbackEngineBannerProps {
+    /**
+     * The explicit fallback rule for this list, if the tenant has configured
+     * one (i.e. `approvalRule.isFallback === true`). When undefined, the
+     * banner renders a placeholder approver list derived from the default
+     * non-user actor labels. Final copy for the default case is still TBD;
+     * we use existing locale strings for now and swap when product confirms.
+     */
+    fallbackRule?: ApprovalRuleWithUser;
+}
+/**
+ * Top-of-list-page banner that surfaces which approvers will be requested
+ * when no other approval rule matches a bill / reimbursement.
+ *
+ * Per Rubal's feedback in the handoff call, the approver list is rendered
+ * as a flat "Vendor Owner or Manager or Admin" listing — replacing the
+ * old arrow-flow format. Both branches (explicit fallback rule vs.
+ * default trio) render through the same actor-list path so the styling
+ * stays consistent.
+ */
+declare const FallbackEngineBanner: ({ fallbackRule }: FallbackEngineBannerProps) => import("react/jsx-runtime").JSX.Element;
+export default FallbackEngineBanner;

package/dist/components/commonSetUp/approval/FormSection.d.ts

@@ -0,0 +1,26 @@
+import { ResponsiveSized } from '../../../context/windowSizeProvider';
+/**
+ * A labelled section wrapper for the approval-rule create/edit form.
+ *
+ * Renders a bold heading + lighter subheading above a bordered card
+ * holding the section's controls. Used to break the form into
+ * "Add Rule", "Set Conditions", and "Set Approval Stages" groups so
+ * each chunk of the rule is visually separated.
+ */
+/**
+ * Layout constants for the create / edit approval-rule form column.
+ *
+ * Exported so other components sharing the column (e.g. the overlap
+ * warning banner that sits above the FormSections) can match the same
+ * responsive width and stay in vertical alignment with the cards.
+ */
+export declare const D: {
+    width: ResponsiveSized;
+};
+export interface FormSectionProps {
+    children: React.ReactNode;
+    heading: string;
+    subheading: string;
+}
+export declare function FormSection({ heading, subheading, children }: FormSectionProps): import("react/jsx-runtime").JSX.Element;
+export default FormSection;

package/dist/components/commonSetUp/approval/IgnoreOverlapModal.d.ts

@@ -0,0 +1,22 @@
+/**
+ * Approval Rules 3.0 — "Proceed with overlapping rules?" confirmation.
+ *
+ * Mounted by the BillPay / Reimbursement detail page when the user
+ * clicks "Ignore & Proceed" in RuleOverlapBanner. Cancel returns to
+ * the form with no side effects (banner remains visible); Proceed
+ * dispatches the underlying save. This is the second-stage gate on
+ * top of the banner itself — once the user acknowledges the overlap,
+ * the rule is created / updated as-is.
+ *
+ * Thin wrapper over the shared ConfirmationPopup, kept as a named
+ * file so the wiring side reads naturally and so the copy lives in
+ * one place.
+ */
+export interface IgnoreOverlapModalProps {
+    /** True while the underlying save dispatch is in flight. */
+    isLoading?: boolean;
+    onCancel: () => void;
+    onProceed: () => void;
+}
+declare const IgnoreOverlapModal: ({ onCancel, onProceed, isLoading, }: IgnoreOverlapModalProps) => import("react/jsx-runtime").JSX.Element;
+export default IgnoreOverlapModal;

package/dist/components/commonSetUp/approval/OperatorIsOrIsNotPicker.d.ts

@@ -0,0 +1,23 @@
+/**
+ * The `is` / `is_not` operator used by both vendor and department
+ * condition rows. Extracted so the option list, locale labels, and
+ * binding shape stay identical between rows.
+ */
+export type IsOrIsNotOperator = "is" | "is_not";
+export interface OperatorIsOrIsNotPickerProps {
+    /**
+     * The label rendered to the left of the picker (e.g. "Vendor"
+     * or "Department"). Each row chooses its own copy so the picker
+     * row reads naturally as "Vendor is …" / "Department is not …".
+     */
+    label: string;
+    /**
+     * Full react-hook-form path to the operator value. Typical values:
+     *   - `vendorCriteria.operator`
+     *   - `departmentCriteria.operator`
+     */
+    name: string;
+    defaultOperator?: IsOrIsNotOperator;
+}
+export declare function OperatorIsOrIsNotPicker({ label, name, defaultOperator, }: OperatorIsOrIsNotPickerProps): import("react/jsx-runtime").JSX.Element;
+export default OperatorIsOrIsNotPicker;

package/dist/components/commonSetUp/approval/RuleOverlapBanner.d.ts

@@ -0,0 +1,61 @@
+import { RuleOverlap } from '@zeniai/client-epic-state';
+import { ApprovalRuleWithUser } from './RuleOverlapCard';
+/**
+ * Approval Rules 3.0 — frontend overlap warning surface.
+ *
+ * Sits above the Add Rule / detail form when 'detectRuleOverlap'
+ * returns a non-empty list. Outer width matches the form column
+ * (same 'FormSection.D.width' tuple) so the banner stacks cleanly
+ * above the first SectionCard.
+ *
+ * Structure (per design):
+ *   ┌─[gold border]──────────────────────────────────────┐
+ *   │ [warm warning fill — header only]                  │
+ *   │   ⚠  Partial rule overlap detected                 │
+ *   │      Conditions partially overlap with…            │
+ *   ├────────────────────────────────────────────────────┤
+ *   │ [grey-5 surface — body]                            │
+ *   │   ┌─ inner rule card ───────────────────────────┐  │
+ *   │   │ Rule name           [SoD][Set at Priority]  │  │
+ *   │   │ Description                                 │  │
+ *   │   │ When: [chip] [chip]                         │  │
+ *   │   │ Then: 1. Require approval from …            │  │
+ *   │   └─────────────────────────────────────────────┘  │
+ *   │                       [Ignore & Proceed] [Edit]    │
+ *   └────────────────────────────────────────────────────┘
+ *
+ * Colors are explicit static tokens per the design (not theme-
+ * adaptive) — the warning surface stays warm-amber in both themes,
+ * the body stays light, the rule card stays white. See the styled
+ * components below for the token-by-token mapping.
+ *
+ * Action buttons sit at the bottom-right of the body. 'Ignore &
+ * Proceed' fires the parent's save flow as-is. 'Edit Existing Rule'
+ * navigates same-tab to the conflicting rule's detail page; when
+ * multiple overlaps are present we suppress this button because it
+ * has no unambiguous target — the user can pick a card via its own
+ * header context (TODO: multi-overlap design pass).
+ */
+export interface RuleOverlapBannerProps {
+    overlaps: RuleOverlap<ApprovalRuleWithUser>[];
+    departmentNamesById?: Record<string, string>;
+    /**
+     * Disables both action buttons while the page is in an in-flight
+     * save (so the user can't double-fire or navigate away mid-write).
+     */
+    disableButtons?: boolean;
+    vendorNamesById?: Record<string, string>;
+    /**
+     * Called when the user clicks Edit Existing Rule. The parent's
+     * connector navigates same-tab to that rule's edit page. Only
+     * invoked when 'overlaps.length === 1'.
+     */
+    onEditExistingRule: (ruleId: string) => void;
+    /**
+     * Called when the user accepts the overlap and wants the save to
+     * proceed. The parent dispatches the underlying save here.
+     */
+    onIgnoreAndProceed: () => void;
+}
+declare const RuleOverlapBanner: ({ overlaps, vendorNamesById, departmentNamesById, onIgnoreAndProceed, onEditExistingRule, disableButtons, }: RuleOverlapBannerProps) => import("react/jsx-runtime").JSX.Element | null;
+export default RuleOverlapBanner;

package/dist/components/commonSetUp/approval/RuleOverlapCard.d.ts

@@ -0,0 +1,31 @@
+import { BillPayApprovalRuleWithUser, RemiApprovalRuleWithUser } from '@zeniai/client-epic-state';
+/**
+ * Shared shape across the two product-specific selectors. Same alias
+ * used in ApprovalRuleSection / FallbackEngineBanner. We accept the
+ * full `WithUser` shape (not just a structural subset) because the
+ * card renders steps with resolved user names.
+ */
+export type ApprovalRuleWithUser = BillPayApprovalRuleWithUser | RemiApprovalRuleWithUser;
+/**
+ * Approval Rules 3.0 — per-rule overlap row inside RuleOverlapBanner.
+ *
+ * Renders the conflicting rule almost identically to the list-page
+ * card (ApprovalRuleSection): name + Priority pill + optional SoD
+ * pill on the right, description below, then 'When:' chips and
+ * 'Then:' step list. The kebab + edit/delete actions are intentionally
+ * omitted — the Edit Existing Rule CTA lives at the banner level and
+ * acts on the rule that this card represents.
+ *
+ * The chip / step rendering is duplicated from ApprovalRuleSection
+ * rather than extracted to a shared file: the two surfaces have
+ * different surrounding chrome and the helpers are small. If a third
+ * consumer ever needs them, extract at that point.
+ */
+export interface RuleOverlapCardProps {
+    departmentNamesById: Record<string, string>;
+    rule: ApprovalRuleWithUser;
+    vendorNamesById: Record<string, string>;
+    dataTestId?: string;
+}
+declare const RuleOverlapCard: ({ rule, vendorNamesById, departmentNamesById, dataTestId, }: RuleOverlapCardProps) => import("react/jsx-runtime").JSX.Element;
+export default RuleOverlapCard;

package/dist/components/commonSetUp/approval/Switch.d.ts

@@ -0,0 +1,23 @@
+/**
+ * Approval Rules 3.0 — boolean toggle primitive.
+ *
+ * Inline iOS-style switch built locally rather than pulling in a new
+ * dependency, because (a) the project does not export a Switch /
+ * Toggle field, and (b) the two current consumers (the Separation of
+ * Duties toggle inside Set Approval Stages, and the "Set as default
+ * fallback" toggle inside Add Rule) want the same shape.
+ *
+ * The control writes a bare boolean to form state under the supplied
+ * field name — no {allOptions, selectedOption} wrapping like the
+ * shared SingleSelectField. That matches the canonical shape of
+ * boolean form slots like isFallback and separationOfDuties so the
+ * screen connector reads them directly without normalisation.
+ */
+export interface SwitchProps {
+    /** react-hook-form field path (e.g. "isFallback" or "separationOfDuties"). */
+    name: string;
+    /** Optional starting value. Defaults to false. */
+    defaultValue?: boolean;
+}
+export declare function Switch({ name, defaultValue }: SwitchProps): import("react/jsx-runtime").JSX.Element;
+export default Switch;