@celigo/api-specs 0.2.128 → 0.2.129

package/dist/sync.yml

@@ -1169,7 +1169,7 @@ paths:
                         numLoadedRecords: 12450
                         numExtractedRecords: 12450
                         numTablesSynced: 3
-                        triggeredBy: user:tyler.lamparter@celigo.com
+                        triggeredBy: user:jane@example.com
                         runType: normal
                       - _id: 6821b00a39db7c2b9cdc0d10
                         flowExecutionGroupId: 6821b00a39db7c2b9cdc0d09
@@ -1347,7 +1347,7 @@ paths:
                     numLoadedRecords: 12450
                     numExtractedRecords: 12450
                     numTablesSynced: 3
-                    triggeredBy: user:tyler.lamparter@celigo.com
+                    triggeredBy: user:jane@example.com
                     runType: normal
                 running:
                   summary: A currently running sync job
@@ -1997,7 +1997,7 @@ paths:
                           type: string
                           description: User display name.
                           examples:
-                            - Tyler Lamparter
+                            - Jane Doe
                     fieldChanges:
                       type: array
                       description: Fields that were modified. Dot-notation paths reach into nested objects.
@@ -2043,7 +2043,7 @@ paths:
                       byUser:
                         _id: 624cb0346309dc3a543733a2
                         email: user@example.com
-                        name: Tyler Lamparter
+                        name: Jane Doe
                       fieldChanges:
                         - fieldPath: name
                           oldValue: ''
@@ -2061,7 +2061,7 @@ paths:
                       byUser:
                         _id: 624cb0346309dc3a543733a2
                         email: user@example.com
-                        name: Tyler Lamparter
+                        name: Jane Doe
                       fieldChanges:
                         - fieldPath: salesforce.refreshToken
                           newValue: '********'
@@ -4142,7 +4142,7 @@ components:
                 Database in the destination warehouse the sync loads into; it must already exist.
                 For Google BigQuery this is the GCP project id the tables are created in
                 (`project.dataset.table`).
-              x-celigo-ui-override: For a BigQuery destination the Create Sync wizard shows no database picker and fills this field with the selected connection's rdbms.bigquery.projectId (IO-195900).
+              x-celigo-ui-override: For a BigQuery destination the Create Sync wizard shows no database picker and fills this field with the selected connection's rdbms.bigquery.projectId.
               examples:
                 - ANALYTICS_DB
             schema:
@@ -4151,7 +4151,7 @@ components:
                 Schema within `database` where the sync creates and loads tables; created on save
                 when it does not exist. For Google BigQuery this is the dataset name, with case
                 preserved.
-              x-celigo-ui-override: For a BigQuery destination the Create Sync wizard labels this field "dataset" and accepts only letters, digits and underscore (no $), starting with a letter or underscore, at most 1024 characters (IO-195900); Snowflake and NSAW validation is unchanged.
+              x-celigo-ui-override: For a BigQuery destination the Create Sync wizard labels this field "dataset" and accepts only letters, digits and underscore (no $), starting with a letter or underscore, at most 1024 characters; Snowflake and NSAW validation is unchanged.
               examples:
                 - salesforce_raw
             tablePrefix:
@@ -4743,13 +4743,13 @@ components:
           readOnly: true
           description: Who or what triggered this sync run (e.g. `"user:email"`, `"schedule"`).
           examples:
-            - user:tyler.lamparter@celigo.com
+            - user:jane@example.com
         canceledBy:
           type: string
           readOnly: true
           description: Who requested cancellation. Present once cancellation has been requested.
           examples:
-            - user:tyler.lamparter@celigo.com
+            - user:jane@example.com
         runType:
           type: string
           readOnly: true
@@ -4785,7 +4785,7 @@ components:
           numLoadedRecords: 12450
           numExtractedRecords: 12450
           numTablesSynced: 3
-          triggeredBy: user:tyler.lamparter@celigo.com
+          triggeredBy: user:jane@example.com
           runType: normal
         - _id: 6821c01c39db7c2b9cdc0e40
           flowExecutionGroupId: 6821c01c39db7c2b9cdc0e39
@@ -4798,7 +4798,7 @@ components:
           numLoadedRecords: 0
           numExtractedRecords: 0
           numTablesSynced: 1
-          triggeredBy: user:tyler.lamparter@celigo.com
+          triggeredBy: user:jane@example.com
           runType: resync
           datasetIds:
             - 6a559b547885d8f93921c2ba
@@ -4833,7 +4833,7 @@ components:
               numLoadedRecords: 12450
               numExtractedRecords: 12450
               numTablesSynced: 3
-              triggeredBy: user:tyler.lamparter@celigo.com
+              triggeredBy: user:jane@example.com
               runType: normal
           totalCount: 1
     SyncTableJob:

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
@@ -15999,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-
@@ -16069,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
@@ -16351,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
@@ -16481,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:
@@ -16607,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}})"]`
@@ -17468,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:
@@ -17517,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:
@@ -17553,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
@@ -19720,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:
@@ -25019,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.
@@ -25201,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
@@ -25224,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.
@@ -25266,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
@@ -25295,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
@@ -25351,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.
@@ -25361,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
@@ -25388,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:
@@ -25504,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
 
@@ -25567,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>"``.
@@ -25592,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
@@ -25895,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
@@ -35277,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
@@ -35285,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
@@ -36029,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
@@ -36054,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)
                 - |-