monday-cli 0.2.0 → 0.4.0

package/dist/api/partial-success-bulk.d.ts

@@ -0,0 +1,480 @@
+/**
+ * Bulk per-item partial-success path for the v0.3-M25
+ * `item update --continue-on-error` flag (`cli-design.md` §6.4
+ * "Bulk per-item partial-success" sub-section).
+ *
+ * **What this module owns.** A thin wrapper around the selected
+ * per-target dispatcher — {@link dispatchSequential} from
+ * `src/api/partial-success-mutation.ts` (default / M25 path) OR
+ * {@link dispatchParallel} from `src/api/parallel-dispatch.ts`
+ * (v0.4-M30 `--concurrency > 1` path) — that drives the matched-
+ * item-ID list through one wire call per item, capturing per-
+ * item failures into the result records rather than aborting
+ * the loop. The wrapper sits BETWEEN the bulk command-action
+ * orchestrator (`src/commands/item/update.ts:runBulk`) and the
+ * shared dispatcher — the action body owns the matched-item-
+ * walk + column-resolution pre-pass + confirmation gate, then
+ * hands the resolved `SelectedMutation` + matched-item IDs to
+ * this wrapper, which fans them out + projects the partial-
+ * success envelope's `data.results[]` records.
+ *
+ * **Why a separate module rather than folding into update.ts.**
+ * Three reasons:
+ *
+ *   1. **Single-source-of-truth for the partial-success contract
+ *      surface.** M13 `update clear-all`, M14 `workspace
+ *      add-users` / `remove-users`, M15 `board add-users`, and
+ *      M25 `item update --continue-on-error` all share the
+ *      `{<id_field>, ok, error?}` per-record shape backed by
+ *      `dispatchSequential`. Keeping M25's wrapper next to its
+ *      family in `src/api/` (rather than buried in a command
+ *      file) keeps the family discoverable + makes future M27
+ *      bulk-write extensions (notification fan-out?) lift
+ *      cleanly into the same module.
+ *
+ *   2. **Action-body size budget.** `src/commands/item/update.ts`
+ *      already runs ~1100 LOC carrying both single-item +
+ *      v0.1 fail-fast bulk paths; adding the partial-success
+ *      branch inline would push it past 1300 and bury the
+ *      `dispatchSequential` integration. The action layer
+ *      branches on `parsed.continueOnError` and dispatches into
+ *      this module's `runPartialSuccessBulkUpdate` instead.
+ *
+ *   3. **Test surface ergonomics.** Per-item partial-success
+ *      tests (mock `client.raw` with a routing predicate that
+ *      flips success/failure per item-ID) read cleaner against
+ *      the wrapper's seam than against the action body's
+ *      branched control flow.
+ *
+ * **What stays at the action layer.** Argv-parse, column
+ * resolution, items_page walk, confirmation gate, dry-run path,
+ * source aggregation seed, and the universal-partial-success
+ * `ok: true` envelope assembly (via `emitMutation`). The
+ * wrapper returns the `data.results[]` array + the per-item
+ * source-leg fold; the action body wires that into the
+ * envelope it would have emitted on the v0.1 fail-fast bulk
+ * path's success branch.
+ *
+ * **Shipped at M25 IMPL (`fe15181`).** Pre-flight contract
+ * diff (`d5839a9`) pinned the module signatures + per-item
+ * result schema + pure-helper bodies; the M25 IMPL feat fills
+ * the runtime body of `runPartialSuccessBulkUpdate` + drops
+ * the `c8 ignore start/stop` block-wraps that surrounded both
+ * the wrapper body and the action-body routing branch at
+ * `src/commands/item/update.ts:runBulk`. The `executeMutation`
+ * lift to `src/api/item-mutation-execute.ts` (renamed
+ * `executeItemMutation`) shipped ahead at `78889df` (R-NEW-29
+ * 3-consumer trigger: single-item + fail-fast bulk + M25
+ * partial-success bulk).
+ *
+ * **v0.4-M30 extension.** Adds the `concurrency` input slot +
+ * the routing branch to {@link dispatchParallel} (new module
+ * `src/api/parallel-dispatch.ts` — runtime body landed at M30
+ * IMPL). When the caller passes `concurrency > 1`, the runtime
+ * fans out per-target dispatches via a bounded async-pool;
+ * absent or `concurrency === 1` preserves the M25 sequential
+ * path verbatim. The per-target dispatch closure is hoisted to
+ * a named local so both routes share the same
+ * `executeItemMutation` + `foldAndRemap` body — keeps the
+ * R-NEW-28 6-axis behavioral-equivalence audit straightforward.
+ * The M30 IMPL also threads an optional `signal?: AbortSignal`
+ * through both dispatchers (axis-6 scheduler short-circuit).
+ *
+ * **Per-item dispatch wiring.** Runtime body routes between
+ * {@link dispatchSequential} (default — `concurrency` absent /
+ * `=== 1`) and {@link dispatchParallel} (v0.4-M30 —
+ * `concurrency > 1`) over `matchedItemIds` with id-field
+ * `'item_id'`. The per-target dispatch callback (shared between
+ * routes verbatim) fires one `executeItemMutation` call.
+ * Successes populate `results[i].item` with the `ProjectedItem`
+ * via a side-map fold; failures land in
+ * `results[i].error: {code, message}` via the dispatcher's
+ * built-in error decoration. `internal_error` codes re-throw
+ * as whole-call (M14 round-2 F1 precedent — schema-drift in
+ * the response MUST NOT be papered over as a per-item failure).
+ *
+ * **`data.summary.failed_count` invariant.** The action body
+ * derives `failed_count` from the result records
+ * (`results.filter((r) => !r.ok).length`); the wrapper does
+ * NOT compute it directly because the summary slot also
+ * carries `matched_count` + `applied_count` + `board_id` —
+ * shapes the action body already owns from the walker + the
+ * matched-item-walk + the argv. Keeping the summary
+ * assembly at the action layer prevents wrapper-vs-action
+ * drift on the partial-success contract's per-summary shape.
+ */
+import { z } from 'zod';
+import { type ProjectedItem } from './item-projection.js';
+import { type PartialSuccessResult } from './partial-success-mutation.js';
+import type { ResolverWarning } from './columns.js';
+import type { SelectedMutation } from './column-values.js';
+import type { MondayClient } from './client.js';
+import type { EnvelopeSource } from './source-aggregator.js';
+/**
+ * Per-item result schema for the partial-success bulk envelope's
+ * `data.results[]` slot. Each record carries `item_id` + `ok` +
+ * either `item` (on success) or `error` (on failure). The two
+ * branches share the discriminator `ok: boolean` — agents read
+ * `r.ok ? r.item : r.error` to dispatch on outcome.
+ *
+ * The `item` slot on success records is the §6.2 `ProjectedItem`
+ * shape (same projection single-item `item update` emits as
+ * `data`). The `error` slot on failure records carries
+ * `{code, message}` populated from the selected dispatcher's
+ * per-target error decoration (`dispatchSequential` or
+ * `dispatchParallel` — same shape per the R-NEW-28 axis-1
+ * equivalence).
+ *
+ * `z.discriminatedUnion` would be the natural shape but the
+ * dispatchers' result records carry a dynamic id-field key
+ * (`{item_id: ..., ok, error?}`) — modelling that as a
+ * per-record union complicates the schema and downstream
+ * consumers' type-narrowing. The flatter shape below carries
+ * `item` + `error` as optionals; the action body's projection
+ * + the wrapper's per-item dispatch enforce the
+ * mutual-exclusion invariant at runtime.
+ */
+export declare const partialSuccessBulkUpdateResultSchema: z.ZodObject<{
+    item_id: z.ZodString;
+    ok: z.ZodBoolean;
+    item: z.ZodOptional<z.ZodObject<{
+        id: z.ZodString;
+        name: z.ZodString;
+        board_id: z.ZodNullable<z.ZodString>;
+        group_id: z.ZodNullable<z.ZodString>;
+        parent_item_id: z.ZodNullable<z.ZodString>;
+        state: z.ZodNullable<z.ZodString>;
+        url: z.ZodNullable<z.ZodString>;
+        created_at: z.ZodNullable<z.ZodString>;
+        updated_at: z.ZodNullable<z.ZodString>;
+        columns: z.ZodRecord<z.ZodString, z.ZodObject<{
+            id: z.ZodString;
+            type: z.ZodString;
+            title: z.ZodOptional<z.ZodString>;
+            text: z.ZodNullable<z.ZodString>;
+            value: z.ZodUnknown;
+            label: z.ZodOptional<z.ZodNullable<z.ZodString>>;
+            index: z.ZodOptional<z.ZodNullable<z.ZodNumber>>;
+            date: z.ZodOptional<z.ZodNullable<z.ZodString>>;
+            time: z.ZodOptional<z.ZodNullable<z.ZodString>>;
+            people: z.ZodOptional<z.ZodArray<z.ZodObject<{
+                id: z.ZodString;
+                kind: z.ZodOptional<z.ZodNullable<z.ZodString>>;
+            }, z.core.$loose>>>;
+        }, z.core.$loose>>;
+    }, z.core.$strict>>;
+    error: z.ZodOptional<z.ZodObject<{
+        code: z.ZodString;
+        message: z.ZodString;
+    }, z.core.$strip>>;
+}, z.core.$strip>;
+export type PartialSuccessBulkUpdateResult = z.infer<typeof partialSuccessBulkUpdateResultSchema>;
+/**
+ * Output `data` shape for the partial-success bulk envelope.
+ * `data.operation` is the literal `"item_update"` (mirrors M14's
+ * add-users / remove-users discriminator at `data.operation`;
+ * agents switch on it to confirm which verb produced the
+ * envelope).
+ *
+ * `data.summary` extends the v0.1 fail-fast bulk-summary with
+ * `failed_count` — items whose per-item dispatch failed under
+ * the `--continue-on-error` path. The invariant
+ * `matched_count === applied_count + failed_count` holds for
+ * every M25 success envelope.
+ */
+export declare const partialSuccessBulkUpdateDataSchema: z.ZodObject<{
+    operation: z.ZodLiteral<"item_update">;
+    summary: z.ZodObject<{
+        matched_count: z.ZodNumber;
+        applied_count: z.ZodNumber;
+        failed_count: z.ZodNumber;
+        board_id: z.ZodString;
+    }, z.core.$strip>;
+    results: z.ZodArray<z.ZodObject<{
+        item_id: z.ZodString;
+        ok: z.ZodBoolean;
+        item: z.ZodOptional<z.ZodObject<{
+            id: z.ZodString;
+            name: z.ZodString;
+            board_id: z.ZodNullable<z.ZodString>;
+            group_id: z.ZodNullable<z.ZodString>;
+            parent_item_id: z.ZodNullable<z.ZodString>;
+            state: z.ZodNullable<z.ZodString>;
+            url: z.ZodNullable<z.ZodString>;
+            created_at: z.ZodNullable<z.ZodString>;
+            updated_at: z.ZodNullable<z.ZodString>;
+            columns: z.ZodRecord<z.ZodString, z.ZodObject<{
+                id: z.ZodString;
+                type: z.ZodString;
+                title: z.ZodOptional<z.ZodString>;
+                text: z.ZodNullable<z.ZodString>;
+                value: z.ZodUnknown;
+                label: z.ZodOptional<z.ZodNullable<z.ZodString>>;
+                index: z.ZodOptional<z.ZodNullable<z.ZodNumber>>;
+                date: z.ZodOptional<z.ZodNullable<z.ZodString>>;
+                time: z.ZodOptional<z.ZodNullable<z.ZodString>>;
+                people: z.ZodOptional<z.ZodArray<z.ZodObject<{
+                    id: z.ZodString;
+                    kind: z.ZodOptional<z.ZodNullable<z.ZodString>>;
+                }, z.core.$loose>>>;
+            }, z.core.$loose>>;
+        }, z.core.$strict>>;
+        error: z.ZodOptional<z.ZodObject<{
+            code: z.ZodString;
+            message: z.ZodString;
+        }, z.core.$strip>>;
+    }, z.core.$strip>>;
+}, z.core.$strip>;
+export type PartialSuccessBulkUpdateData = z.infer<typeof partialSuccessBulkUpdateDataSchema>;
+/**
+ * Inputs for the partial-success bulk dispatch helper.
+ *
+ * - `client` — the `MondayClient` (or test-double) the wrapper
+ *   calls `client.raw` against. Action layer hands this in
+ *   after `resolveClient` has run.
+ * - `boardId` — the board the matched items live on. Threaded
+ *   through to the per-item `executeMutation` call AND to the
+ *   per-item `foldAndRemap` archived-column probe.
+ * - `matchedItemIds` — IDs from the items_page walker; non-
+ *   empty (action layer's empty-match branch emits a clean
+ *   no-op envelope before reaching this helper).
+ * - `mutation` — the pre-resolved `SelectedMutation` (one of
+ *   `change_simple_column_value` / `change_column_value` /
+ *   `change_multiple_column_values`). Column resolution + the
+ *   synthetic-name fold run ONCE at the action layer, BEFORE
+ *   the per-item dispatch — this helper sees the resolved
+ *   `SelectedMutation` and fans it out.
+ * - `createLabelsIfMissing` — Monday's
+ *   `change_*_column_value.create_labels_if_missing` flag.
+ *   Threaded through to every per-item dispatch.
+ *
+ * **Codex round-1 P1-1 fix.** Per-item failures must inherit
+ * the SAME error-code remap the v0.1 fail-fast bulk path
+ * applies — a stale-cache `validation_failed` remaps to the
+ * stable `column_archived` code agents key off (cli-design
+ * §6.5). The wrapper's per-item dispatch callback fires
+ * `foldAndRemap` BEFORE throwing into the selected dispatcher
+ * (`dispatchSequential` or `dispatchParallel` — both apply
+ * the same per-target error decoration) so
+ * the per-record `error.code` in `data.results[]` matches the
+ * shape the fail-fast path would have surfaced as the
+ * top-level `error.code`. That requires the same context the
+ * fail-fast remap needs:
+ *
+ * - `resolverWarnings` — folded into the remapped error's
+ *   `details.resolver_warnings` slot. Same shape the fail-fast
+ *   path carries via `foldResolverWarningsIntoError`.
+ * - `remapColumnIds` — every translated column ID. The remap
+ *   probe scans them in order and remaps to the first
+ *   archived one. Single-column callers pass a one-element
+ *   array; multi-column callers pass every column they tried
+ *   to write (Codex M5b finding #3 precedent).
+ * - `env` — process env for the `refreshBoardMetadata` cache
+ *   call inside the remap probe.
+ * - `noCache` — flag pass-through to the remap probe.
+ * - `resolutionSource` — `'live' | 'cache' | 'mixed'`. The
+ *   remap probe fires ONLY when the original resolution was
+ *   cache-sourced; a `live` resolution already saw the live
+ *   archived flag, so a `validation_failed` after live
+ *   resolution is genuine.
+ *
+ * The helper returns `{ results }`. The action layer:
+ *   1. derives `failed_count` from `results.filter(r => !r.ok)`,
+ *   2. folds the dispatch source signal (always `'live'`) into
+ *      the `SourceAggregator` via
+ *      `sourceAgg.record(PARTIAL_SUCCESS_BULK_DISPATCH_SOURCE,
+ *      null)` — exported constant rather than a bare literal,
+ *   3. assembles the `data.summary` slot with
+ *      `matched_count` / `applied_count` / `failed_count` /
+ *      `board_id`,
+ *   4. emits the partial-success envelope via `emitMutation`,
+ *      passing `apiVersion` only (no `lastResponse` capture —
+ *      per-item `request_id`s aren't a useful aggregate
+ *      signal; the partial-success envelope carries per-item
+ *      outcomes inside `data.results[]` instead).
+ */
+export interface RunPartialSuccessBulkUpdateInputs {
+    readonly client: MondayClient;
+    readonly boardId: string;
+    readonly matchedItemIds: readonly string[];
+    readonly mutation: SelectedMutation;
+    readonly createLabelsIfMissing: boolean | undefined;
+    readonly resolverWarnings: readonly ResolverWarning[];
+    readonly remapColumnIds: readonly string[];
+    readonly env: NodeJS.ProcessEnv;
+    readonly noCache: boolean;
+    readonly resolutionSource: 'live' | 'cache' | 'mixed';
+    /**
+     * v0.4-M30 `--concurrency <N>` argv slot (cli-design §9.3 +
+     * §6.4 "Bulk per-item partial-success — Parallel dispatch").
+     * `undefined` or `1` routes through `dispatchSequential`
+     * (byte-equivalent to the v0.3-M25 path); `> 1` routes
+     * through {@link dispatchParallel} (bounded async-pool).
+     * Action layer's argv parser pins the value to
+     * `[MIN_CONCURRENCY, MAX_CONCURRENCY]` (1..32) before reaching
+     * this helper.
+     */
+    readonly concurrency: number | undefined;
+    /**
+     * v0.4-M30 SIGINT / abort threading. When the runner aborts
+     * `ctx.signal`, both dispatchers check `signal.aborted` at the
+     * iteration / worker-loop boundary and re-throw the signal's
+     * reason whole-call (mirrors {@link dispatchParallel} axis-6).
+     * In-flight wire calls abort via the existing
+     * `MondayClient.signal` configured at construction time
+     * (the client threads its signal into every fetch). Optional
+     * — omitting it preserves v0.3-M25 behaviour exactly for
+     * callers that don't need cooperative abort.
+     */
+    readonly signal?: AbortSignal;
+}
+/**
+ * Result returned by {@link runPartialSuccessBulkUpdate} to the
+ * action layer.
+ *
+ * - `results` — the array of per-item records the helper built
+ *   via the selected dispatcher (`dispatchSequential` or
+ *   `dispatchParallel`) + the per-item projection callback.
+ *   Direct mirror of `data.results[]` in the §6.4 envelope.
+ *   **Mutable array** so the action layer can pass
+ *   it directly to `partialSuccessBulkUpdateDataSchema.parse`
+ *   (zod's `z.array(...)` infers a mutable array — wrapping
+ *   `readonly` would force a spread at the call site).
+ *
+ * The wrapper does NOT return the last wire response — mirrors
+ * the v0.1 fail-fast bulk path's `emitMutation` call which
+ * passes only `apiVersion` (the per-item `request_id`s aren't
+ * a useful aggregate signal; the partial-success envelope
+ * carries per-item outcomes inside `data.results[]` instead).
+ *
+ * The dispatch source signal (always `'live'` post-dispatch
+ * — every Monday mutation counts as a `live` leg per
+ * `SourceAggregator`'s precedent) is folded into the action
+ * layer's `SourceAggregator` via
+ * `sourceAgg.record(PARTIAL_SUCCESS_BULK_DISPATCH_SOURCE, null)`
+ * rather than returned from the wrapper. The constant is
+ * exported for the call site to read against a named symbol
+ * rather than a bare string literal.
+ */
+export interface RunPartialSuccessBulkUpdateResult {
+    readonly results: PartialSuccessBulkUpdateResult[];
+}
+/**
+ * Constant source signal the partial-success bulk dispatch
+ * contributes to the action layer's `SourceAggregator`. Always
+ * `'live'` post-dispatch — every Monday mutation counts as a
+ * `live` leg. Exported so the action layer's
+ * `sourceAgg.record(...)` call site reads against a named
+ * constant rather than a bare string literal.
+ */
+export declare const PARTIAL_SUCCESS_BULK_DISPATCH_SOURCE: EnvelopeSource;
+/**
+ * Drives the per-item dispatch loop under `--continue-on-error`.
+ *
+ * Implementation (M25 impl `78889df` refactor + this commit;
+ * extended at v0.4-M30 pre-flight with the `concurrency` routing
+ * branch):
+ *
+ *   1. Loop {@link dispatchSequential} (default / M25 path) OR
+ *      {@link dispatchParallel} (v0.4-M30 `--concurrency > 1`
+ *      path; runtime body landed at M30 IMPL) over
+ *      `matchedItemIds` with id-field `'item_id'`.
+ *   2. Per-item dispatch callback fires
+ *      {@link executeItemMutation} against the resolved
+ *      `SelectedMutation`. On a {@link MondayCliError} catch,
+ *      run {@link foldAndRemap} with `resolverWarnings` +
+ *      `remapColumnIds` + `env` + `noCache` + `resolutionSource`
+ *      from the inputs BEFORE re-throwing into the selected
+ *      dispatcher (`dispatchSequential` or `dispatchParallel`).
+ *      This makes the per-record `error.code` in
+ *      `data.results[]` carry the SAME stable code
+ *      (`column_archived` after a stale-cache
+ *      `validation_failed` remap) that the v0.1 fail-fast
+ *      path would have surfaced at the top level — Codex
+ *      round-1 P1-1 contract requirement (cli-design §6.5
+ *      stable-code rule applies uniformly across the bulk
+ *      fail-modes).
+ *   3. On success, capture the `ProjectedItem` into a side
+ *      map keyed by `item_id`.
+ *   4. After the loop, walk the result rows (from whichever
+ *      dispatcher fired — `dispatchSequential` by default;
+ *      {@link dispatchParallel} when `concurrency > 1`) and
+ *      fold the per-item `ProjectedItem` from the side
+ *      map into each `results[i].item` slot via
+ *      {@link foldPartialSuccessBulkResult}. Failure records
+ *      already carry `error: {code, message}` (with the
+ *      foldAndRemap-applied code) via the dispatcher's built-in
+ *      error decoration (both routes share the same per-target
+ *      error capture contract).
+ *   5. Return `{results}` — the action layer folds the
+ *      constant `'live'` dispatch source via
+ *      `sourceAgg.record(PARTIAL_SUCCESS_BULK_DISPATCH_SOURCE,
+ *      null)` and emits the envelope.
+ *
+ * **`internal_error` re-throw escape hatch.** Per M14 round-2
+ * F1 / round-3 F1, both dispatchers re-throw `internal_error`
+ * whole-call so schema-drift in the response surfaces as
+ * top-level `ok: false` rather than per-record — papering over
+ * `internal_error` would hide the malformed-response signal
+ * agents need to know about. The wrapper inherits this
+ * behaviour by NOT wrapping the dispatcher's re-throw —
+ * `foldAndRemap` only ever runs against {@link MondayCliError}
+ * instances, and it NEVER converts a non-internal_error into
+ * internal_error, so the re-throw path through the selected
+ * dispatcher remains the canonical schema-drift surface (axis
+ * 2 of the R-NEW-28 6-axis equivalence — identical between
+ * `dispatchSequential` and `dispatchParallel`).
+ *
+ * **Non-`MondayCliError` re-throw.** Programmer-bug exceptions
+ * (TypeError, RangeError, etc.) raised by the executor or by
+ * `foldAndRemap`'s refresh probe propagate through the selected
+ * dispatcher's non-CliError re-throw branch unchanged, surfacing
+ * as whole-call `internal_error` via the runner's catch-all
+ * (mirrors M14's pattern at `users-fan-out-mutation.ts` and the
+ * documented behaviour at `partial-success-mutation.ts` —
+ * R-NEW-28 axis 3, also identical across both routes).
+ */
+export declare const runPartialSuccessBulkUpdate: (inputs: RunPartialSuccessBulkUpdateInputs) => Promise<RunPartialSuccessBulkUpdateResult>;
+/**
+ * Pure helper — folds a per-target result row produced by the
+ * selected dispatcher (`dispatchSequential` or
+ * `dispatchParallel`) + a `ProjectedItem` side-map entry into
+ * the partial-success-bulk per-item record shape this module
+ * emits to the action layer. Both dispatchers populate the row
+ * with the same `{item_id, ok, error?}` shape (axis 1 of the
+ * R-NEW-28 6-axis equivalence) so the fold is route-agnostic.
+ *
+ * The helper is **shipped as a real implementation** (not a
+ * stub) so the pre-flight Codex review can verify the
+ * projection shape against the contract pinned in cli-design
+ * §6.4 inline. M25 implementation reuses the helper unchanged.
+ *
+ * `record` is the row produced by the selected dispatcher with
+ * id-field `'item_id'` — carries `{item_id, ok, error?}` per
+ * the partial-success contract. `projectedItem` is the
+ * `ProjectedItem` the per-item dispatch callback captured on
+ * success (`undefined` on failure).
+ *
+ * Returns the per-item shape with `item` populated only when
+ * the dispatch succeeded; `error` populated only when it
+ * failed. The mutual-exclusion invariant is enforced at the
+ * boundary: success records never carry `error`, failure
+ * records never carry `item`.
+ */
+export declare const foldPartialSuccessBulkResult: (record: PartialSuccessResult, projectedItem: ProjectedItem | undefined) => PartialSuccessBulkUpdateResult;
+/**
+ * Pure helper — derives the `data.summary` slot from the
+ * matched-item count + the per-item results array. The
+ * `matched_count === applied_count + failed_count` invariant
+ * is enforced here; a mismatch throws `internal_error` since
+ * it would indicate a wrapper-layer bug (some matched item
+ * neither succeeded nor failed). Shipped as a real
+ * implementation so the pre-flight Codex review can verify the
+ * shape against cli-design §6.4 inline.
+ */
+export declare const buildPartialSuccessBulkSummary: ({ matchedCount, boardId, results, }: {
+    readonly matchedCount: number;
+    readonly boardId: string;
+    readonly results: readonly PartialSuccessBulkUpdateResult[];
+}) => PartialSuccessBulkUpdateData["summary"];
+//# sourceMappingURL=partial-success-bulk.d.ts.map

package/dist/api/partial-success-bulk.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"partial-success-bulk.d.ts","sourceRoot":"","sources":["../../src/api/partial-success-bulk.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GAwGG;AAEH,OAAO,EAAE,CAAC,EAAE,MAAM,KAAK,CAAC;AAExB,OAAO,EAAuB,KAAK,aAAa,EAAE,MAAM,sBAAsB,CAAC;AAC/E,OAAO,EAGL,KAAK,oBAAoB,EAC1B,MAAM,+BAA+B,CAAC;AAIvC,OAAO,KAAK,EAAE,eAAe,EAAE,MAAM,cAAc,CAAC;AACpD,OAAO,KAAK,EAAE,gBAAgB,EAAE,MAAM,oBAAoB,CAAC;AAC3D,OAAO,KAAK,EAAE,YAAY,EAAE,MAAM,aAAa,CAAC;AAChD,OAAO,KAAK,EAAE,cAAc,EAAE,MAAM,wBAAwB,CAAC;AAE7D;;;;;;;;;;;;;;;;;;;;;;;GAuBG;AACH,eAAO,MAAM,oCAAoC;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;iBAU/C,CAAC;AAEH,MAAM,MAAM,8BAA8B,GAAG,CAAC,CAAC,KAAK,CAClD,OAAO,oCAAoC,CAC5C,CAAC;AAEF;;;;;;;;;;;;GAYG;AACH,eAAO,MAAM,kCAAkC;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;iBAS7C,CAAC;AAEH,MAAM,MAAM,4BAA4B,GAAG,CAAC,CAAC,KAAK,CAChD,OAAO,kCAAkC,CAC1C,CAAC;AAEF;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GAkEG;AACH,MAAM,WAAW,iCAAiC;IAChD,QAAQ,CAAC,MAAM,EAAE,YAAY,CAAC;IAC9B,QAAQ,CAAC,OAAO,EAAE,MAAM,CAAC;IACzB,QAAQ,CAAC,cAAc,EAAE,SAAS,MAAM,EAAE,CAAC;IAC3C,QAAQ,CAAC,QAAQ,EAAE,gBAAgB,CAAC;IACpC,QAAQ,CAAC,qBAAqB,EAAE,OAAO,GAAG,SAAS,CAAC;IACpD,QAAQ,CAAC,gBAAgB,EAAE,SAAS,eAAe,EAAE,CAAC;IACtD,QAAQ,CAAC,cAAc,EAAE,SAAS,MAAM,EAAE,CAAC;IAC3C,QAAQ,CAAC,GAAG,EAAE,MAAM,CAAC,UAAU,CAAC;IAChC,QAAQ,CAAC,OAAO,EAAE,OAAO,CAAC;IAC1B,QAAQ,CAAC,gBAAgB,EAAE,MAAM,GAAG,OAAO,GAAG,OAAO,CAAC;IACtD;;;;;;;;;OASG;IACH,QAAQ,CAAC,WAAW,EAAE,MAAM,GAAG,SAAS,CAAC;IACzC;;;;;;;;;;OAUG;IACH,QAAQ,CAAC,MAAM,CAAC,EAAE,WAAW,CAAC;CAC/B;AAED;;;;;;;;;;;;;;;;;;;;;;;;;;;GA2BG;AACH,MAAM,WAAW,iCAAiC;IAChD,QAAQ,CAAC,OAAO,EAAE,8BAA8B,EAAE,CAAC;CACpD;AAED;;;;;;;GAOG;AACH,eAAO,MAAM,oCAAoC,EAAE,cAAuB,CAAC;AAE3E;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GAiEG;AACH,eAAO,MAAM,2BAA2B,GACtC,QAAQ,iCAAiC,KACxC,OAAO,CAAC,iCAAiC,CAmH3C,CAAC;AAEF;;;;;;;;;;;;;;;;;;;;;;;;;GAyBG;AACH,eAAO,MAAM,4BAA4B,GACvC,QAAQ,oBAAoB,EAC5B,eAAe,aAAa,GAAG,SAAS,KACvC,8BA6DF,CAAC;AAEF;;;;;;;;;GASG;AACH,eAAO,MAAM,8BAA8B,GAAI,qCAI5C;IACD,QAAQ,CAAC,YAAY,EAAE,MAAM,CAAC;IAC9B,QAAQ,CAAC,OAAO,EAAE,MAAM,CAAC;IACzB,QAAQ,CAAC,OAAO,EAAE,SAAS,8BAA8B,EAAE,CAAC;CAC7D,KAAG,4BAA4B,CAAC,SAAS,CAuBzC,CAAC"}