@celigo/api-specs 0.2.127 → 0.2.129

package/dist/import.yml

@@ -849,12 +849,12 @@ paths:
                 value:
                   data:
                     - _id: 5d67ab3992080024596e0d8f
-                      email: nirav.pranami@celigo.com
+                      email: jane@example.com
                       verified: true
                       developer: true
-                      name: sai kaivalya
-                      role: Associate QA Engineer
-                      company: celigo
+                      name: Jane Doe
+                      role: Engineer
+                      company: acme
                       createdAt: '2019-08-29T10:38:50.396Z'
                       lastModified: '2024-09-25T14:17:50.802Z'
                   importConfig:
@@ -903,8 +903,8 @@ paths:
                               data:
                                 nlobjFieldIds:
                                   custrecord_user_id: 5d67ab3992080024596e0d8f
-                                  custrecord_user_email: nirav.pranami@celigo.com
-                                  custrecord_user_name: sai kaivalya
+                                  custrecord_user_email: jane@example.com
+                                  custrecord_user_name: Jane Doe
                                   custrecord_user_onboarded: 'true'
                                 nlobjSublistIds: {}
                           originalSize: 1
@@ -1998,30 +1998,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
 
@@ -2033,13 +2022,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:
@@ -2050,8 +2038,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
@@ -2098,15 +2085,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
@@ -2169,16 +2155,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}}}}'
@@ -2270,9 +2246,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``
 
@@ -2752,9 +2726,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
 
@@ -3030,7 +3003,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 —
@@ -3410,8 +3383,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:
@@ -3890,25 +3863,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}}}"]`
 
@@ -3979,8 +3949,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
@@ -4067,10 +4037,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
@@ -4147,8 +4113,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-
@@ -4218,8 +4184,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
@@ -4248,6 +4214,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
@@ -4402,9 +4384,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-
@@ -4472,9 +4453,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
@@ -4503,6 +4484,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
@@ -4629,6 +4622,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
 
@@ -4662,19 +4681,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
@@ -4701,8 +4735,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
@@ -5100,8 +5134,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:
@@ -5226,7 +5260,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}})"]`
@@ -6087,8 +6121,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:
@@ -6136,8 +6169,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:
@@ -6172,8 +6205,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
@@ -8339,10 +8372,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:
@@ -13305,7 +13336,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
@@ -14344,7 +14375,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
@@ -14783,7 +14814,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
@@ -14811,9 +14842,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
@@ -16081,7 +16111,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.
@@ -16263,13 +16293,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
@@ -16286,7 +16312,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.
@@ -16328,11 +16354,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
@@ -16357,11 +16378,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
@@ -16413,8 +16429,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.
@@ -16423,17 +16438,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
@@ -16450,8 +16457,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:
@@ -16566,9 +16573,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
 
@@ -16629,7 +16635,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>"``.
@@ -16654,9 +16660,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

package/dist/job.yml

@@ -424,8 +424,8 @@ paths:
         - |-
           Returns a paged collection of currently running jobs for the dashboard.
           The request body supports filtering by integration, flow, status, and
-          application.  The platform requires ``sandbox`` in the body; Ora is
-          production-only so it always sends ``false``.
+          application.  ``sandbox`` is deprecated; when a caller still sends it,
+          ``false`` selects production.
         - |-
           Do not send time_gt or time_lte; they are not on this request. To find jobs
           stuck for longer than a threshold, compare each job's createdAt or startedAt