@celigo/api-specs 0.2.127 → 0.2.129

package/dist/tool.yml

@@ -4338,7 +4338,7 @@ components:
               no message text) and never cascades or promotes on its own; `Draft`
               descendants are kept as they are, and a `Draft` parent does not gate
               its children. The UI's Set inactive on a parent marks the parent and
-              every child `Inactive` (IO-166197). Re-enabling a child
+              every child `Inactive`. Re-enabling a child
               means re-enabling its ancestors in the same payload. Edits that keep
               existing rows must carry their stored status forward — rewriting a
               `Draft` or `Inactive` row to `Active` turns a row the user parked
@@ -5377,7 +5377,7 @@ components:
                 no message text) and never cascades or promotes on its own; `Draft`
                 descendants are kept as they are, and a `Draft` parent does not gate
                 its children. The UI's Set inactive on a parent marks the parent and
-                every child `Inactive` (IO-166197). Re-enabling a child
+                every child `Inactive`. Re-enabling a child
                 means re-enabling its ancestors in the same payload. Edits that keep
                 existing rows must carry their stored status forward — rewriting a
                 `Draft` or `Inactive` row to `Active` turns a row the user parked
@@ -6085,7 +6085,7 @@ components:
                         ``{record: {...}, settings: ..., job: ...}`` (plus
                         ``fileMeta`` on file-provider steps) — the
                         same runtime-context envelope Handlebars / SQL /
-                        GraphQL specialists consume.  ``mappings[].extract``
+                        GraphQL templates render against.  ``mappings[].extract``
                         JSONPath values MUST include the ``record.`` segment
                         — for example ``"$.record.orderId"`` or
                         ``"$.record.customer.email"``.  PLACEHOLDER extracts
@@ -6113,9 +6113,8 @@ components:
                       ``inputContext: record`` makes the contract
                       self-documenting and prevents the transform from
                       drifting into envelope mode if an upstream change ever
-                      changes the platform default.  The TransformsAgent
-                      reads this value off the transform config and threads
-                      it into the generator's prompt so the JSONPath form
+                      changes the platform default.  Read this value before
+                      writing ``mappings[].extract`` so the JSONPath form
                       matches the runtime root.
                     - |-
                       ## fileMeta on file-provider steps
@@ -13579,30 +13578,19 @@ components:
               would be bare ``{{{jsonSerialize record}}}`` with nothing
               around it, you don't need a template at all.
 
-              Production frequency: roughly 1 in 3 active HTTPImports leaves
-              this field empty (~35% null / empty array); closer to 1 in 2
-              once you count the additional ~12% of body entries that are
-              blank strings.  The dominant case is "no body template".
-
               Leave undefined for:
               - REST APIs accepting JSON CRUD payloads (the destination
                 already wants exactly the post-mapped record shape).
-              - GraphQL destinations — do NOT author the body template here.
-                The dedicated GraphQL specialist owns the
-                ``{query, operationName, variables}`` shape and routes the
-                post-mapped record into ``variables`` automatically.  Roughly
-                96% of all wrapped-``jsonSerialize record`` uses in production
-                are GraphQL mutations; every one of those should go through
-                the GraphQL specialist, not through this body template.
               - Any case where the destination wants the mapped record as-is.
+
+              GraphQL destinations are different: the body is the stringified
+              ``{query, operationName, variables}`` envelope described under
+              ``formType``, with the post-mapped record passed in
+              ``variables``.
             - |-
-              ## SET THIS FIELD when one of the production patterns below applies
+              ## SET THIS FIELD when one of the patterns below applies
 
-              Production grounds these patterns: 36,445 active body entries
-              across HTTPImports in the last 30 days (Celigo-internal users
-              excluded).  Choose the pattern that fits the destination's
-              shape, then write marker ``instructions`` describing intent
-              (let the Handlebars specialist produce the literal template).
+              Choose the pattern that fits the destination's shape.
 
               ### Pattern A — ``{{{jsonSerialize record}}}`` inside a static wrapper
 
@@ -13614,13 +13602,12 @@ components:
               destination's field shape; the body owns the transport-level
               scaffolding.
 
-              Production frequency: roughly 115 / 36,445 (0.3%) of body
-              entries when the destination is non-GraphQL.  Rare but real;
-              the use cases that fit are obvious when the user describes
-              them ("wrap each request in a SQS-style message envelope",
-              "add a batch header with timestamp + interface name", etc.).
+              Rare for non-GraphQL destinations, but real; the use cases
+              that fit are obvious when the user describes them ("wrap each
+              request in a SQS-style message envelope", "add a batch header
+              with timestamp + interface name", etc.).
 
-              Real production shapes:
+              Typical shapes:
               - Message-bus envelope:
                 ``{"MessageBody": {"class": "EntityUpdate", "payload": {{{jsonSerialize record}}}}}``
               - Metadata wrap:
@@ -13631,8 +13618,7 @@ components:
               NEVER emit BARE ``{{{jsonSerialize record}}}`` with no wrapper.
               The platform sends the post-mapped record as JSON automatically
               when body is undefined; bare ``jsonSerialize record`` produces
-              identical wire output and shows up in 0.7% of production body
-              entries — every one of those is redundant config the user has
+              identical wire output, so it is redundant config the user has
               to maintain for zero benefit.
 
               ### Pattern B — Batch / page wrapper around mapped records
@@ -13679,15 +13665,14 @@ components:
               anti-pattern is the ``jsonSerialize`` wrap, not any particular
               path shape.
 
-              - Production frequency: 15 / 36,445 (0.04%) — essentially never.
+              - Essentially never needed.
               - Failure mode: the body validator sees the PRE-mapped sample
                 shape, can't resolve the post-mapped path during validation,
                 and ``jsonSerialize`` on an unresolved path raises
                 ``Helper {{jsonSerialize}} expects an argument`` — the
                 template fails validation even when it would render at
-                runtime.  The specialist enters a retry loop, tries variations
-                (``getValue`` wrappers, alternate paths), and converges on
-                failure.
+                runtime.  Variations (``getValue`` wrappers, alternate paths)
+                fail the same way.
 
               If you find yourself wanting to reference a per-field
               post-mapped scalar wrapped in ``jsonSerialize``, your situation
@@ -13750,16 +13735,6 @@ components:
                 before choosing: form-data APIs get the parts array above;
                 multipart/related APIs get the hand-authored document. Never
                 mix the two shapes in one body.
-            - |-
-              ## Marker instructions style
-
-              When emitting a ``$agent: handlebars`` marker at this field,
-              write the ``instructions`` as INTENT (what the body should
-              produce: destination fields, shape, encoding), not as literal
-              Handlebars syntax.  Embedding literal ``{{{jsonSerialize record.X}}}``
-              in the instructions risks the specialist following it verbatim
-              even when a simpler template would work — one of the ways the
-              per-field anti-pattern above gets introduced.
           examples:
             - - '{"name": "{{record.name}}", "email": "{{record.email}}"}'
             - - '{"requestData": {{{jsonSerialize record}}}}'
@@ -13851,9 +13826,7 @@ components:
             - |-
               The value MUST match the ``name`` of a lookup entry in ``http.lookups``.
               The lookup config itself (HTTP path, method, extract,
-              fallback chain) is authored separately — typically by the LookupsAgent
-              specialist via a ``$agent:
-              lookup`` marker.
+              fallback chain) is defined separately, in that entry.
             - |-
               ## Mutually exclusive with ``existingExtract``
 
@@ -14333,9 +14306,8 @@ components:
 
               The Celigo platform persists lookups in TWO locations on an HTTP
               import: top-level ``lookups`` and ``http.lookups``.  Both arrays
-              MUST hold byte-for-byte identical content.  The import engine
-              and the MappingsAgent both maintain this mirror on every save —
-              callers never have to write both manually.
+              MUST hold byte-for-byte identical content, so write both on
+              every save.
             - |-
               ## Static vs dynamic vs cached
 
@@ -14611,7 +14583,7 @@ components:
               computedObject.fileName." — an error the platform labels source `internal` although the
               template is the cause. The run-time-proven way to keep the source file's name on a
               `blob: true` import is `{{record.fileMeta.fileName}}` on `file.fileName` with this field
-              omitted (the production runs of one FTP blob import set exactly that); the same template
+              omitted (recorded runs of an FTP blob import set exactly that); the same template
               on this field has not been run. The field's editor preview (data version 1, its default)
               exposes the record as `data` —
               the `{blobKey, fileMeta}` record on a blob import, the page's record array otherwise —
@@ -14991,8 +14963,8 @@ components:
               ## Mirror invariant
               The Celigo platform persists lookups in TWO locations on a JDBC
               import: top-level `lookups` and `jdbc.lookups`. Both arrays
-              must hold byte-for-byte identical content — the MappingsAgent
-              writes both on every save.
+              must hold byte-for-byte identical content, so write both on every
+              save.
           x-celigo-agent:
             - lookup
     Mongodb:
@@ -15471,25 +15443,22 @@ components:
                   substitutions FIRST against the incoming source record (pre-mapped),
                   then the substituted expression is sent to NetSuite as a saved-search query.
                 - |-
-                  ## Handlebars conventions (production grounded)
+                  ## Handlebars conventions
 
                   - **No `record.` prefix** — substitutions reference top-level
                     source-record fields directly.  `{{{id}}}` / `{{{Id}}}` /
                     `{{{externalid}}}` / `{{{[Internal ID]}}}` — NOT
-                    `{{{record.id}}}`.  Production: only 122 / 55,328 expressions
-                    (0.2%) use the `record.` prefix; the dominant convention is
-                    top-level paths.
-                  - **Triple braces `{{{...}}}`** are the preferred form (78% of
-                    production); double-brace `{{...}}` also works for cases
-                    where you want the platform's default HTML-escape (rare in
-                    this field).
+                    `{{{record.id}}}`.  Top-level paths are the established
+                    convention.
+                  - **Triple braces `{{{...}}}`** are the preferred form;
+                    double-brace `{{...}}` also works for cases where you want
+                    the platform's default HTML-escape (rare in this field).
                   - **Bracket notation for field names with spaces or special
                     chars**: `{{{[Field With Spaces]}}}`, `{{{[Internal ID]}}}`.
-                    Anchored to ~10% of production expressions.
                 - |-
                   ## Canonical patterns
 
-                  ### Simple lookup by internal ID (most common — 8.4% of all expressions)
+                  ### Simple lookup by internal ID (most common)
 
                   `["internalid","is","{{{id}}}"]`
 
@@ -15560,8 +15529,8 @@ components:
                   `is` / `equalto` / `internalid anyof` value to `isempty` before the
                   search. On `restletVersion: suiteapp2.0` that search is not treated as
                   "no match": it can return existing records, and `addupdate` then
-                  updates one of them — an unrelated record receives the mapping (seen
-                  in production as `cant_modify_sub` on a customer the record never
+                  updates one of them — an unrelated record receives the mapping (for
+                  example, a `cant_modify_sub` error on a customer the record never
                   named). SuiteBundle and SuiteApp 1.0 discard a blank `internalid`
                   match and create. Design so the operational lookup never renders
                   empty: key it on a value every record carries (the source id stored
@@ -15648,10 +15617,6 @@ components:
             - |-
               Validated via the dedicated `PUT /v1/netsuiteDA/previewImportMappingFields`
               endpoint (NOT `/v1/processors/mapperProcessor`).
-            - |-
-              Managed by the MappingsAgent (`$agent: mapping`) — resource-authoring
-              agents must emit a specialist marker at this field rather than
-              generating the mapping inline.
           properties:
             fields:
               type: array
@@ -15728,8 +15693,8 @@ components:
                         this block ONLY when the destination record type genuinely requires the
                         subrecord.
                       - |-
-                        **Real-world `recordType` values** (ranked by
-                        production frequency across NetSuite DA imports):
+                        **Common `recordType` values** (most common
+                        first):
                         * `inventorydetail` — by far the most common.
                           Serial / lot / bin assignments on sales-order,
                           item-fulfillment, purchase-order, and inventory-
@@ -15799,8 +15764,8 @@ components:
                         type: string
                         description: |
                           Secondary reference-field identifier used on a
-                          small fraction of subrecord blocks in production
-                          (~3%).  Exact semantics are not publicly
+                          small fraction of subrecord blocks.  Exact
+                          semantics are not publicly
                           documented by Celigo — match the value on
                           existing resources when present; do NOT
                           synthesize one.  Leave unset unless a template
@@ -15829,6 +15794,22 @@ components:
                         existing record: on an `add`-only operation every record fails with
                         `The mapping condition:"record_updated" not supported for the
                         operation`. It works on `addupdate` and `update`.
+                      - |-
+                        The condition is one of the fixed `when` values — there is no
+                        predicate over a source field ("when `customer.id` is not empty",
+                        "when `channel.name` is Point of Sale" cannot be written here).
+                        `extract_not_empty` is the only source-driven gate: on a lookup row
+                        it reads the row's `extract`, and when that is empty the row is
+                        skipped and the field is left unset — nothing substitutes a value.
+                        Value-dependent behaviour (a fallback record when the key is
+                        missing) belongs inside the lookup's `expression` (see
+                        `lookups[].expression`).
+                      - |-
+                        Two rows with the same `generate` are not a fallback pair: the
+                        last row for a destination decides it alone — when its condition
+                        skips it the field stays empty even if an earlier row produced a
+                        value, and when it applies it overwrites the earlier row's value
+                        (`ignore_if_set` reads the target record, not an earlier row).
                     properties:
                       lookupName:
                         type: string
@@ -15983,9 +15964,8 @@ components:
                               this block ONLY when the destination record type genuinely requires the
                               subrecord.
                             - |-
-                              **Real-world `recordType` values** (ranked
-                              by production frequency across NetSuite DA
-                              imports):
+                              **Common `recordType` values** (most
+                              common first):
                               * `inventorydetail` — by far the most
                                 common.  Serial / lot / bin assignments on
                                 sales-order, item-fulfillment, purchase-
@@ -16053,9 +16033,9 @@ components:
                               type: string
                               description: |
                                 Secondary reference-field identifier used
-                                on a small fraction of subrecord blocks
-                                in production (~3%).  Exact semantics are
-                                not publicly documented by Celigo — match
+                                on a small fraction of subrecord blocks.
+                                Exact semantics are not publicly
+                                documented by Celigo — match
                                 the value on existing resources when
                                 present; do NOT synthesize one.  Leave
                                 unset unless a template clearly requires
@@ -16084,6 +16064,18 @@ components:
                               rows in live verification. Do not rely on that tolerance — use
                               `when: record_updated` only on operations that can update
                               records (`addupdate` / `update`).
+                            - |-
+                              The condition is one of the fixed `when` values — the same
+                              closed set as body rows, with no predicate over a source
+                              field; `extract_not_empty` skips the row on the lines whose
+                              extract is empty and leaves that line's field unset. Two
+                              sublist rows with the same `generate` are not a fallback
+                              pair either, and the order rule is not the body rows': among
+                              extract rows the last row decides each line alone (a skipped
+                              last row leaves the line's field unset even when an earlier
+                              row produced a value), while a hard-coded row's value lands
+                              on every line whatever its position — a later conditional
+                              extract row does not override it.
                           properties:
                             lookupName:
                               type: string
@@ -16210,6 +16202,32 @@ components:
                     shows what the expression produced for that line. With
                     `allowFailures: true` the `default` value is used instead
                     and no error is raised. Give every branch an output.
+                  - |-
+                    ## An empty substitution searches `isempty`
+
+                    When the source path a criterion reads is null or absent
+                    (`["custentity_celigo_etail_cust_id","is","{{{customer.id}}}"]`
+                    on an order with no customer), the engine does not fail on
+                    the missing input: it searches the field with an `isempty`
+                    criterion, so the lookup now matches every target record
+                    whose field is BLANK. Two or more such records fail the
+                    record with `VALUE_LOOKUP_FAILED` — `More than one match
+                    for "[<field>,"isempty"]" for the record type "<recordType>"`
+                    (the message quotes the search field, never the empty
+                    source path); none fail it as `Could not find a match`;
+                    exactly one silently resolves to that record. Keep an empty
+                    key out of the search inside the expression — branch on
+                    the key: `{{#if customer.id}}[["custentity_celigo_etail_cust_id",
+                    "is","{{{customer.id}}}"]]{{else}}[["internalid","anyof",
+                    "<fallback internal id>"]]{{/if}}` routes records without a
+                    key to a fallback record while records with a key keep
+                    fail-on-miss; or render a value that can never match in the
+                    else branch and set `allowFailures: true` with `default`.
+                    A `searchField` / `operator` lookup (no `expression`) never
+                    reaches this state: an empty extract fails the record with
+                    `STATIC_MAPPING_ERROR` — `Exported value is empty/undefined
+                    for the field: $.<path>` — and resolves to `default` when
+                    `allowFailures` is true.
                   - |-
                     ## The mapping preview cannot evaluate `[*]` inside a block-helper argument
 
@@ -16243,19 +16261,34 @@ components:
               useDefaultOnMultipleMatches:
                 type: boolean
                 description: |-
-                  Controls behaviour when the search matches more than one
-                  record. When true, the `default` value is returned instead
-                  of raising an ambiguous-match error. When false (default),
-                  multiple matches are treated as a failure.
+                  When true and `allowFailures` is also true, a search that
+                  matches more than one record resolves to `default` instead
+                  of failing the record. Has no effect while `allowFailures`
+                  is false — an ambiguous match then fails the record whatever
+                  this flag says.
+                x-celigo-ai-guidance:
+                  - |-
+                    Set it together with `allowFailures: true` whenever the
+                    search value can be empty or duplicated: with
+                    `allowFailures: true` alone an ambiguous match resolves to
+                    ONE of the matching records with no error, and with this
+                    flag alone the record still fails `More than one match`.
+                    Every ambiguous match then becomes `default`, a genuinely
+                    duplicated key included — when that must still fail, keep
+                    `allowFailures` false and handle the empty key in the
+                    `expression` instead (see `expression`).
               allowFailures:
                 type:
                   - boolean
                   - 'null'
                 description: |-
                   When true, a lookup miss (no matching record and no
-                  `default`) resolves to `null` and the import continues.
-                  When false (default), a miss halts the record. May be
-                  stored as null (treated as unset).
+                  `default`) resolves to `null` and the import continues, and
+                  a search matching more than one record resolves to one of
+                  them unless `useDefaultOnMultipleMatches` routes it to
+                  `default`. When false (default), a miss and an ambiguous
+                  match both halt the record. May be stored as null (treated
+                  as unset).
               map:
                 type:
                   - object
@@ -16282,8 +16315,8 @@ components:
               ## Mirror invariant
               The Celigo platform persists NetSuite Distributed Import lookups in
               TWO locations: `netsuite_da.lookups` and top-level `lookups`.
-              Both arrays must hold byte-for-byte identical content — the
-              MappingsAgent writes both on every save.
+              Both arrays must hold byte-for-byte identical content, so write
+              both on every save.
             - |-
               ## One context for body and sublist lookups
               Every lookup's `expression` renders against the whole source
@@ -16412,8 +16445,8 @@ components:
             **Mirror invariant**
             The Celigo platform persists lookups in TWO locations on an RDBMS
             import: top-level `lookups` and `rdbms.lookups`. Both arrays
-            must hold byte-for-byte identical content — the MappingsAgent
-            writes both on every save.
+            must hold byte-for-byte identical content, so write both on every
+            save.
           items:
             type: object
             properties:
@@ -16538,7 +16571,7 @@ components:
               - **Nested fields**: `{{record.properties.email}}` (auto-quoted)
                 or `{{{record.properties.email}}}` (raw).
             - |-
-              ## EXAMPLES (production-grounded)
+              ## EXAMPLES
 
               - INSERT (string columns, auto-quoted): `["INSERT INTO customers (name, email) VALUES ({{record.name}}, {{record.email}})"]`
               - INSERT (mixed numeric + string): `["INSERT INTO orders (qty, sku) VALUES ({{{record.qty}}}, {{record.sku}})"]`
@@ -17399,8 +17432,7 @@ components:
           "wrapper" JavaScript module that invokes a custom function (typically to
           integrate with a system Celigo doesn't have a first-class connector for).
         - |-
-          Wrapper imports use Mapper 1.0 for field mappings and the generic Celigo lookup shape.
-          The MappingsAgent operates in `v1_standard` mode for this adaptor type —
+          Wrapper imports use Mapper 1.0 for field mappings and the generic Celigo lookup shape:
           mappings live in `resource.mapping` (fields/lists) and lookups mirror at
           `resource.lookups` and `resource.wrapper.lookups`.
       properties:
@@ -17448,8 +17480,8 @@ components:
               ## Mirror invariant
               The Celigo platform persists lookups in TWO locations on a
               Wrapper import: top-level `lookups` and `wrapper.lookups`.
-              Both arrays must hold byte-for-byte identical content — the
-              MappingsAgent writes both on every save.
+              Both arrays must hold byte-for-byte identical content, so write
+              both on every save.
       if:
         not:
           propertyNames:
@@ -17484,8 +17516,8 @@ components:
             **Mirror invariant**
             The Celigo platform stores lookups in TWO locations on a Salesforce
             import resource: top-level ``lookups`` and ``salesforce.lookups``.
-            Both arrays must hold byte-for-byte identical content — the
-            MappingsAgent writes both on every save.
+            Both arrays must hold byte-for-byte identical content, so write
+            both on every save.
 
             **Static vs dynamic lookups**
             - **Static** — only ``map`` + optional ``default``. No Salesforce
@@ -19651,10 +19683,8 @@ components:
               update this field — the wrapper itself stays the same shape,
               just points at a different Tool.
             - |-
-              The agent that authors the wrapper does not author the Tool itself;
-              Tool authoring goes through the Tools page agent's `create_tool` / `update_tool` tools (or,
-              when invoked from a flow / API / Tool dispatch path,
-              through the Tool Builder which delegates to the Tool engine's brief-based entry point).
+              Writing the wrapper does not create or change the Tool itself;
+              author the Tool as its own resource through `/v1/tools`.
           examples:
             - 69ce8ae7cbbb51405ae42ae5
         overrides:
@@ -24950,7 +24980,7 @@ components:
               Optional on a `blob: true` file-provider import: when omitted the platform reads the
               record's root `blobKey` — the field a blob export emits on its `{blobKey, fileMeta}`
               record — so a file-transfer flow needs no `blobKeyPath`. Observed on an FTP import
-              (production runs writing files with no `blobKeyPath`) and on a Google Drive folder
+              (recorded runs writing files with no `blobKeyPath`) and on a Google Drive folder
               upload (`http.type: file`, the marketplace file-transfer template's shape); other
               file providers were not probed. Set it only when a response mapping placed the key
               elsewhere; on those two providers its absence is not a cause of upload failures.
@@ -25132,13 +25162,9 @@ components:
             - |-
               JavaScript hook references attached to lifecycle stages of the import.
               Engage hooks ONLY when the user explicitly wants scripting OR a requirement
-              cannot be expressed through declarative specialists (mapping / filter /
+              cannot be expressed through declarative configuration (mappings / filters /
               responseTransform).
               Hooks bypass the platform's declarative validation, so use them sparingly.
-            - |-
-              Phase A authoring scope: ``preMap`` and ``postMap`` only.
-              ``postSubmit`` and ``postAggregate`` are Phase B's territory (they author
-              against the real destination response).
           properties:
             preMap:
               type: object
@@ -25155,7 +25181,7 @@ components:
                   before the mapping sees them (drop archived records,
                   normalize date strings, split a record into many).  Don't
                   engage for static value substitution or simple field
-                  renames — that's the mapping specialist's job.
+                  renames — mappings handle those.
 
                   Runtime contract: ``options.data[]`` (the page of upstream
                   records) → array of the same length.
@@ -25197,11 +25223,6 @@ components:
                   Post-submit JavaScript hook — runs AFTER each batch of
                   destination writes, on the destination's response.
 
-                  **Phase B owns this slot.**  Phase A must NOT emit a
-                  ``$agent`` marker here (see "Phase A vs Phase B ownership"
-                  in the engine prompt).  Phase B authors this against the
-                  real probe response.
-
                   Runtime contract: ``options.responseData[]`` (one per
                   submitted record; ``{statusCode, errors, _json, ...}`` —
                   ``id`` is present on real runs but absent from the
@@ -25226,11 +25247,6 @@ components:
                   ``invalid_hook`` ("unsupported postAggregate hook") —
                   never emit it for non-file adaptors.
 
-                  **Phase B owns this slot.**  Phase A must NOT emit a
-                  ``$agent`` marker here (see "Phase A vs Phase B ownership"
-                  in the engine prompt).  Phase B authors this against the
-                  real probe response.
-
                   Runtime contract: ``options.postAggregateData``
                   (``{success, _json, code, message, source}``) → no return
                   value; side effects only (logging, notifying, downstream
@@ -25282,8 +25298,7 @@ components:
 
               REQUIRED for ``SalesforceImport`` and ``WrapperImport``: these
               adaptors must use Mapper 1.0; Mapper 2.0 is not supported for
-              them.  The agent's adaptor→mode classifier routes them here
-              automatically.  ``NetSuiteDistributedImport`` is also V1-required
+              them.  ``NetSuiteDistributedImport`` is also V1-required
               but uses a NetSuite-specific variant at its adaptor-scoped copy
               ``netsuite_da.mapping`` (richer sublist / subRecord vocabulary) —
               not this field.
@@ -25292,17 +25307,9 @@ components:
               ``FTPImport``, ``JDBCImport``, etc.) when the user explicitly asks
               for Mapper 1.0 — e.g. when the import wraps a legacy v1 connector
               or is being migrated from an older integration.  Those adaptors
-              default to Mapper 2.0 at the top-level ``mappings`` (plural) field;
-              see :mod:`celigo_agents.helpers.mappings.mapping_mode` for the
-              adaptor → default-mode classifier.  Do not emit a marker here
-              unsolicited; the v2 default produces better output for modern
-              connectors.
-            - |-
-              ## Specialist marker
-
-              Managed by the MappingsAgent (``$agent: mapping``) — resource-
-              authoring agents must emit a specialist marker at this field
-              rather than generating mapping content inline.
+              default to Mapper 2.0 at the top-level ``mappings`` (plural) field.
+              Do not set this field unsolicited; the v2 default produces better
+              output for modern connectors.
             - |-
               Allowed (but not the default) on other import adaptors such as
               ``HTTPImport``, ``RDBMSImport``, ``FTPImport``, and
@@ -25319,8 +25326,8 @@ components:
 
               Lookups referenced by ``lookupName`` live on the top-level
               ``resource.lookups`` array (mirrored under the adaptor key for
-              adaptors that maintain their own copy — see the mirror pattern in
-              the MappingsAgent architecture). Lookups are independent of this
+              adaptors that maintain their own copy — see the mirror invariant
+              on ``lookups``). Lookups are independent of this
               mapping: they are neither created nor cleared automatically when
               this mapping changes.
           properties:
@@ -25435,9 +25442,8 @@ components:
             - |-
               ## Mirror invariant
 
-              Both arrays MUST hold byte-for-byte identical content. The
-              MappingsAgent writes both on every save and treats them as a
-              single logical field.
+              Both arrays MUST hold byte-for-byte identical content: write
+              both on every save and treat them as a single logical field.
             - |-
               ## Shape
 
@@ -25498,7 +25504,7 @@ components:
               - ``envelope``: the mapper sees a wrapped object of the shape
                 ``{record: {...}, settings: ..., job: ...}`` — the same
                 runtime-context envelope Handlebars / SQL / GraphQL
-                specialists consume. ``mappings[].extract`` JSONPath values
+                templates render against. ``mappings[].extract`` JSONPath values
                 MUST include the ``record.`` segment — for example
                 ``"$.record.orderId"`` or ``"$.record.customer.email"``.
                 PLACEHOLDER extracts use ``"$.record.PLACEHOLDER_<field>"``.
@@ -25523,9 +25529,9 @@ components:
               platform, but emitting ``inputContext: record`` makes the
               contract self-documenting and prevents the mapper from drifting
               into envelope mode if an upstream change ever changes the
-              platform default. The MappingsAgent reads this value off the
-              resource and threads it into the mapping generator's prompt so
-              the JSONPath form matches the runtime root.
+              platform default. Read this value before writing
+              ``mappings[].extract`` so the JSONPath form matches the runtime
+              root.
         settingsForm:
           x-celigo-agent:
             - settings_form
@@ -25826,9 +25832,9 @@ components:
               Substitute ``<modifiedTimestampField>`` with the actual
               timestamp field the target entity exposes in its response.  Do
               NOT invent or copy field names from an example authored for a
-              different endpoint -- an unknown field name causes a runtime
-              "unknown property" / "invalid column" error the build cannot
-              catch.  See the engine's filter-field grounding principle.
+              different endpoint -- an unknown field name causes an
+              "unknown property" / "invalid column" error that surfaces only
+              at run time.
 
               For Salesforce, this field is required and has the following default values:
               - LastModifiedDate
@@ -35208,7 +35214,7 @@ components:
                         `[application · stage=apiCall] search.createColumn:
                         Missing a required argument: name`.  The platform
                         validation runs before any column data is read, so
-                        the build fails fast.
+                        the export fails fast.
                       - |-
                         ## NAME MUST BE A SEARCH COLUMN, NOT A BODY FIELD
                         NetSuite distinguishes between body fields (the
@@ -35216,9 +35222,8 @@ components:
                         search columns (the fields exposed for filtering /
                         sorting in saved searches, like `shipaddress1`).
                         `columns[].name` MUST be a search column ID, not
-                        a body field ID.  See the SEARCH COLUMNS section of
-                        the metadata fetcher output for the valid search
-                        column names for the chosen `recordType`.
+                        a body field ID: take it from the chosen
+                        `recordType`'s SEARCH COLUMNS list.
                       - |-
                         ## EXAMPLES
                         - `"internalid"` -- the record's internal id
@@ -35960,7 +35965,7 @@ components:
                   If the folder internal ID is required to be dynamic based on the data you are integrating,
                   you can specify the JSON path to the field in your data containing the folder
                   internal ID values instead — with DOUBLE braces (e.g. {{record.folderId}}).
-                  Production usage is dominantly a static numeric ID; dynamic substitution is rare.
+                  Default to a static numeric ID; dynamic substitution is the exception.
                 - |-
                   ## FIELD BEHAVIOR:
                   - Identifies the specific folder in NetSuite's file cabinet to export files from
@@ -35985,7 +35990,7 @@ components:
                   - May be linked to folder creation or folder search operations to retrieve valid IDs.
                 - |-
                   ## EXAMPLES:
-                  - "12345" - Static folder internal ID (the dominant production form)
+                  - "12345" - Static folder internal ID (the usual form)
                   - "67890" - Another valid folder internal ID
                   - "{{record.folderId}}" - Dynamic folder ID from integration data (double braces)
                 - |-