npm - @wildo-ai/systems-of-record - Versions diffs - 1.1.6 - Mend

@wildo-ai/systems-of-record 1.1.6

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.

Files changed (34) hide show

package/LICENSE ADDED Viewed

@@ -0,0 +1,34 @@
+Copyright (c) 2026 P2C Consulting, s.à r.l.-S
+RCS Luxembourg B307591
+6C, Porte de France, L-4360 Esch-sur-Alzette, Luxembourg
+All rights reserved.
+This software and its accompanying materials (the "Software") are the
+confidential and proprietary property of P2C Consulting, s.à r.l.-S (the
+"Licensor"). The Software is made available for viewing only. No licence,
+right, or permission of any kind is granted by its publication or by its
+availability on any package registry or source repository.
+Without the Licensor's prior written permission, you may not use, copy,
+reproduce, modify, adapt, translate, merge, publish, distribute, sublicense,
+sell, host, or create derivative works of the Software, in whole or in part,
+nor use it to provide a service to any third party.
+Publication of the Software in any public registry is for distribution to
+authorised recipients and for technical evaluation of its packaging only. It
+does not place the Software in the public domain, does not constitute an open
+source release, and does not waive any right of the Licensor.
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+LICENSOR BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN
+ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION
+WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
+Third-party components distributed with the Software remain governed by their
+own licences.
+Contact: P2C Consulting, s.à r.l.-S, 6C, Porte de France, L-4360
+Esch-sur-Alzette, Luxembourg.

package/dist/esm/microsoft-dataverse.system-of-record.d.ts ADDED Viewed

@@ -0,0 +1,3 @@
+import type { SystemOfRecordVendorFacet } from '@wildo-ai/saas-models/external-data';
+export declare const MicrosoftDataverseSystemOfRecordFacet: SystemOfRecordVendorFacet;
+//# sourceMappingURL=microsoft-dataverse.system-of-record.d.ts.map

package/dist/esm/microsoft-dataverse.system-of-record.d.ts.map ADDED Viewed

	@@ -0,0 +1 @@
1	+ {"version":3,"file":"microsoft-dataverse.system-of-record.d.ts","sourceRoot":"","sources":["../../../src/microsoft-dataverse.system-of-record.ts"],"names":[],"mappings":"AA8CA,OAAO,KAAK,EAAE,yBAAyB,EAAE,MAAM,qCAAqC,CAAC;AAUrF,eAAO,MAAM,qCAAqC,EAAE,yBA4EnD,CAAC"}

package/dist/esm/microsoft-dataverse.system-of-record.js ADDED Viewed

@@ -0,0 +1,124 @@
+/**
+ * Microsoft Dataverse (Dynamics 365 Customer Engagement), as a SYSTEM OF RECORD.
+ *
+ * spec-cite: Microsoft Learn, "Use the Microsoft Dataverse Web API" —
+ * https://learn.microsoft.com/en-us/power-apps/developer/data-platform/webapi/overview
+ *
+ * ## It pages by CONTINUATION, and that is why this facet exists rather than `odata`
+ *
+ * The Dataverse Web API does not support `$skip`. The engine's read-through LIST compiles `$top` and
+ * `$skip` for every page after the first, so an instance declared against the generic `odata` facet
+ * would serve page one and be refused on page two — an application that looks correct in a demo and
+ * fails the first time somebody scrolls.
+ *
+ * spec-cite: Microsoft Learn, "Query data using the Web API" —
+ * https://learn.microsoft.com/en-us/power-apps/developer/data-platform/webapi/query-data-web-api
+ * (that page enumerates the OData query options the Web API does not support).
+ *
+ * The consequence an author should know before choosing this vendor: page N costs N requests, and
+ * the engine refuses past a bound rather than walking indefinitely. A deep collection wants a filter.
+ *
+ * ## Deterministic order is not decoration here
+ *
+ * Its paging cookie is built from the LAST ROW of the previous page under the query's own order, and
+ * its own documentation is explicit that without a deterministic order the same record can appear on
+ * more than one page. The engine appends the binding's key components to `$orderby` under
+ * continuation paging for exactly that reason — a duplicated row is harmless, a SKIPPED one is
+ * silently absent.
+ *
+ * spec-cite: Microsoft Learn, "Page results using OData from Microsoft Dataverse Web API" —
+ * "Deterministic ordering is important" / "Without proper ordering, the same record can appear in
+ * more than one page."
+ *
+ * ## Why three Microsoft refs exist and only this one is the facet
+ *
+ * The catalogue holds `microsoft-dataverse`, `microsoft-dynamics-365` and `microsoft-dynamics-crm` —
+ * three scraped refs over one Web API. `microsoft-dataverse` is the name the API itself uses, so it
+ * is the one an instance names. The other two are deliberately not given facets: a second facet for
+ * the same API would be a second answer to "how is this read", free to disagree.
+ *
+ * ## Partitioning is absent, and that is #1058's
+ *
+ * Dataverse partitions by business unit (`_owningbusinessunit_value`). The partition vocabulary does
+ * not exist yet, and declaring one here would claim a narrowing that does not happen — so until
+ * #1058 an application reading this vendor sees every business unit its service identity can see.
+ */
+import { HttpApiTransportDialect, SystemOfRecordCredentialKind } from '@wildo-ai/saas-models';
+import { ExternalDataIncrementalExtractionMode, ODATA_ENTITY_TAG_CONTROL_INFORMATION, SystemOfRecordAssertionHeaderPolicy, SystemOfRecordAssertionSigningAlgorithm, SystemOfRecordClientAuthenticationPlacement, SystemOfRecordODataListPaging, } from '@wildo-ai/saas-models/external-data';
+export const MicrosoftDataverseSystemOfRecordFacet = {
+    vendor: 'microsoft-dataverse',
+    dialects: [HttpApiTransportDialect.ODATA],
+    odataListPaging: SystemOfRecordODataListPaging.NEXT_LINK_ONLY,
+    /*
+     * #1722 — every Dataverse table carries `modifiedon`, and the Web API tracks changes (delta links, deleted entities)
+     * for a table that has change tracking enabled. Enabling it is per table, so a pipeline on a table without it is
+     * refused at its first delta read, naming the cause.
+     * spec-cite: Microsoft Learn, "Use change tracking to synchronize data with external systems"
+     * (https://learn.microsoft.com/en-us/power-apps/developer/data-platform/use-change-tracking-synchronize-data-external-systems),
+     * "Retrieve changes for a table using the Web API".
+     */
+    incrementalExtractionModes: [ExternalDataIncrementalExtractionMode.ODATA_MODIFIED_AT, ExternalDataIncrementalExtractionMode.ODATA_DELTA_LINK],
+    /*
+     * #1722 — Dataverse keeps change tracking for `ExpireChangeTrackingInDays` (seven by default) and says only that "the
+     * system throws an exception" past it; its error-code reference names that exception, and it is not the protocol's
+     * `410`. Stating the code lets the pass start over with a full read instead of failing every tick. The HTTP status
+     * Dataverse pairs it with is not documented, so the code alone decides (UNPROVEN against a live table, #2009).
+     * spec-cite: Microsoft Learn, "Web service error codes" (https://learn.microsoft.com/en-us/power-apps/developer/data-platform/reference/web-service-error-codes)
+     * — row `0x80044352`, `ExpiredVersionStamp`: "Version stamp associated with the client has expired. Please perform a
+     * full sync."
+     */
+    odataExpiredChangePositionErrorCodes: ['0x80044352'],
+    /*
+     * #1726 — every Dataverse row carries an entity tag, and an update or delete sent with it as `If-Match` is refused
+     * with `412 Precondition Failed` when the row changed since. So a binding may declare `VERSION_CHECKED` on a field
+     * mapped to the tag and get a real optimistic-concurrency check.
+     *
+     * spec-cite: Microsoft Learn, "Perform conditional operations using the Web API (Microsoft Dataverse)" —
+     * https://learn.microsoft.com/en-us/power-apps/developer/data-platform/webapi/perform-conditional-operations-using-web-api
+     * ("Dataverse generates a weakly validating `@odata.etag` property for every entity instance", and the two 412
+     * examples under "Apply optimistic concurrency").
+     *
+     * UNCONFIRMED, and stated rather than hidden: Dataverse documents optimistic concurrency as supported "on all
+     * out-of-box tables enabled for offline sync and all custom tables" (Microsoft Learn, "Optimistic concurrency"), and
+     * the SDK refuses a version-checked update on another table (`OptimisticConcurrencyNotEnabled`). What the Web API
+     * answers to an `If-Match` on such a table was not measured; a refusal there reaches the caller as a remote refusal.
+     *
+     * Dataverse also UPSERTS: a `PATCH` to a key that no longer exists creates the row. The write dialect therefore sends
+     * `If-Match` on every update (the row's tag, or `*`), which the same page documents as the way to prevent it.
+     */
+    rowVersionField: ODATA_ENTITY_TAG_CONTROL_INFORMATION,
+    addressSlots: [
+        {
+            slug: 'baseUrl',
+            required: true,
+            description: "This environment's Web API service root, version included "
+                + '(https://<org>.crm<region>.dynamics.com/api/data/v9.2). The organization URL alone is not '
+                + 'enough: entity-set names are appended to the versioned data path.',
+        },
+    ],
+    credentialOffers: [
+        {
+            kind: SystemOfRecordCredentialKind.OAUTH2_CLIENT_CREDENTIALS_SECRET,
+            // spec-cite: Microsoft Learn, "Microsoft identity platform and the OAuth 2.0 client credentials
+            // flow" — https://learn.microsoft.com/en-us/entra/identity-platform/v2-oauth2-client-creds-grant
+            clientAuthentication: SystemOfRecordClientAuthenticationPlacement.REQUEST_BODY,
+            tokenLifetimeFallbackSeconds: 900,
+        },
+        {
+            kind: SystemOfRecordCredentialKind.OAUTH2_CLIENT_CREDENTIALS_CERTIFICATE,
+            /*
+             * UNCONFIRMED, and left so deliberately: Entra's certificate credential is documented as
+             * identifying the signing key by an `x5t` thumbprint in the assertion header, and that is what
+             * this declares — but the page was not fetched at authoring time, so it is the plan's
+             * expectation rather than a quotation (`external-specification-citations.md` §4). An operator
+             * meeting `invalid_client` with a certificate credential should read the vendor's assertion
+             * format before assuming the engine is wrong.
+             */
+            assertionHeaderPolicy: SystemOfRecordAssertionHeaderPolicy.X509_THUMBPRINT_DERIVED,
+            assertionSigningAlgorithm: SystemOfRecordAssertionSigningAlgorithm.RS256,
+            assertionLifetimeSeconds: 300,
+            tokenLifetimeFallbackSeconds: 900,
+        },
+    ],
+};
+//# sourceMappingURL=microsoft-dataverse.system-of-record.js.map

package/dist/esm/microsoft-dataverse.system-of-record.js.map ADDED Viewed

@@ -0,0 +1 @@

+ {"version":3,"file":"microsoft-dataverse.system-of-record.js","sourceRoot":"","sources":["../../../src/microsoft-dataverse.system-of-record.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GA4CG;AACH,OAAO,EAAE,uBAAuB,EAAE,4BAA4B,EAAE,MAAM,uBAAuB,CAAC;AAE9F,OAAO,EACL,qCAAqC,EACrC,oCAAoC,EACpC,mCAAmC,EACnC,uCAAuC,EACvC,2CAA2C,EAC3C,6BAA6B,GAC9B,MAAM,qCAAqC,CAAC;AAE7C,MAAM,CAAC,MAAM,qCAAqC,GAA8B;IAC9E,MAAM,EAAE,qBAAqB;IAC7B,QAAQ,EAAE,CAAC,uBAAuB,CAAC,KAAK,CAAC;IACzC,eAAe,EAAE,6BAA6B,CAAC,cAAc;IAC7D;;;;;;;OAOG;IACH,0BAA0B,EAAE,CAAC,qCAAqC,CAAC,iBAAiB,EAAE,qCAAqC,CAAC,gBAAgB,CAAC;IAC7I;;;;;;;;OAQG;IACH,oCAAoC,EAAE,CAAC,YAAY,CAAC;IACpD;;;;;;;;;;;;;;;;;OAiBG;IACH,eAAe,EAAE,oCAAoC;IACrD,YAAY,EAAE;QACZ;YACE,IAAI,EAAE,SAAS;YACf,QAAQ,EAAE,IAAI;YACd,WAAW,EACT,4DAA4D;kBAC1D,4FAA4F;kBAC5F,mEAAmE;SACxE;KACF;IACD,gBAAgB,EAAE;QAChB;YACE,IAAI,EAAE,4BAA4B,CAAC,gCAAgC;YACnE,gGAAgG;YAChG,iGAAiG;YACjG,oBAAoB,EAAE,2CAA2C,CAAC,YAAY;YAC9E,4BAA4B,EAAE,GAAG;SAClC;QACD;YACE,IAAI,EAAE,4BAA4B,CAAC,qCAAqC;YACxE;;;;;;;eAOG;YACH,qBAAqB,EAAE,mCAAmC,CAAC,uBAAuB;YAClF,yBAAyB,EAAE,uCAAuC,CAAC,KAAK;YACxE,wBAAwB,EAAE,GAAG;YAC7B,4BAA4B,EAAE,GAAG;SAClC;KACF;CACF,CAAC","sourcesContent":["/**\n * Microsoft Dataverse (Dynamics 365 Customer Engagement), as a SYSTEM OF RECORD.\n *\n * spec-cite: Microsoft Learn, \"Use the Microsoft Dataverse Web API\" —\n * https://learn.microsoft.com/en-us/power-apps/developer/data-platform/webapi/overview\n *\n * ## It pages by CONTINUATION, and that is why this facet exists rather than `odata`\n *\n * The Dataverse Web API does not support `$skip`. The engine's read-through LIST compiles `$top` and\n * `$skip` for every page after the first, so an instance declared against the generic `odata` facet\n * would serve page one and be refused on page two — an application that looks correct in a demo and\n * fails the first time somebody scrolls.\n *\n * spec-cite: Microsoft Learn, \"Query data using the Web API\" —\n * https://learn.microsoft.com/en-us/power-apps/developer/data-platform/webapi/query-data-web-api\n * (that page enumerates the OData query options the Web API does not support).\n *\n * The consequence an author should know before choosing this vendor: page N costs N requests, and\n * the engine refuses past a bound rather than walking indefinitely. A deep collection wants a filter.\n *\n * ## Deterministic order is not decoration here\n *\n * Its paging cookie is built from the LAST ROW of the previous page under the query's own order, and\n * its own documentation is explicit that without a deterministic order the same record can appear on\n * more than one page. The engine appends the binding's key components to `$orderby` under\n * continuation paging for exactly that reason — a duplicated row is harmless, a SKIPPED one is\n * silently absent.\n *\n * spec-cite: Microsoft Learn, \"Page results using OData from Microsoft Dataverse Web API\" —\n * \"Deterministic ordering is important\" / \"Without proper ordering, the same record can appear in\n * more than one page.\"\n *\n * ## Why three Microsoft refs exist and only this one is the facet\n *\n * The catalogue holds `microsoft-dataverse`, `microsoft-dynamics-365` and `microsoft-dynamics-crm` —\n * three scraped refs over one Web API. `microsoft-dataverse` is the name the API itself uses, so it\n * is the one an instance names. The other two are deliberately not given facets: a second facet for\n * the same API would be a second answer to \"how is this read\", free to disagree.\n *\n * ## Partitioning is absent, and that is #1058's\n *\n * Dataverse partitions by business unit (`_owningbusinessunit_value`). The partition vocabulary does\n * not exist yet, and declaring one here would claim a narrowing that does not happen — so until\n * #1058 an application reading this vendor sees every business unit its service identity can see.\n */\nimport { HttpApiTransportDialect, SystemOfRecordCredentialKind } from '@wildo-ai/saas-models';\nimport type { SystemOfRecordVendorFacet } from '@wildo-ai/saas-models/external-data';\nimport {\n ExternalDataIncrementalExtractionMode,\n ODATA_ENTITY_TAG_CONTROL_INFORMATION,\n SystemOfRecordAssertionHeaderPolicy,\n SystemOfRecordAssertionSigningAlgorithm,\n SystemOfRecordClientAuthenticationPlacement,\n SystemOfRecordODataListPaging,\n} from '@wildo-ai/saas-models/external-data';\n\nexport const MicrosoftDataverseSystemOfRecordFacet: SystemOfRecordVendorFacet = {\n vendor: 'microsoft-dataverse',\n dialects: [HttpApiTransportDialect.ODATA],\n odataListPaging: SystemOfRecordODataListPaging.NEXT_LINK_ONLY,\n /*\n * #1722 — every Dataverse table carries `modifiedon`, and the Web API tracks changes (delta links, deleted entities)\n * for a table that has change tracking enabled. Enabling it is per table, so a pipeline on a table without it is\n * refused at its first delta read, naming the cause.\n * spec-cite: Microsoft Learn, \"Use change tracking to synchronize data with external systems\"\n * (https://learn.microsoft.com/en-us/power-apps/developer/data-platform/use-change-tracking-synchronize-data-external-systems),\n * \"Retrieve changes for a table using the Web API\".\n */\n incrementalExtractionModes: [ExternalDataIncrementalExtractionMode.ODATA_MODIFIED_AT, ExternalDataIncrementalExtractionMode.ODATA_DELTA_LINK],\n /*\n * #1722 — Dataverse keeps change tracking for `ExpireChangeTrackingInDays` (seven by default) and says only that \"the\n * system throws an exception\" past it; its error-code reference names that exception, and it is not the protocol's\n * `410`. Stating the code lets the pass start over with a full read instead of failing every tick. The HTTP status\n * Dataverse pairs it with is not documented, so the code alone decides (UNPROVEN against a live table, #2009).\n * spec-cite: Microsoft Learn, \"Web service error codes\" (https://learn.microsoft.com/en-us/power-apps/developer/data-platform/reference/web-service-error-codes)\n * — row `0x80044352`, `ExpiredVersionStamp`: \"Version stamp associated with the client has expired. Please perform a\n * full sync.\"\n */\n odataExpiredChangePositionErrorCodes: ['0x80044352'],\n /*\n * #1726 — every Dataverse row carries an entity tag, and an update or delete sent with it as `If-Match` is refused\n * with `412 Precondition Failed` when the row changed since. So a binding may declare `VERSION_CHECKED` on a field\n * mapped to the tag and get a real optimistic-concurrency check.\n *\n * spec-cite: Microsoft Learn, \"Perform conditional operations using the Web API (Microsoft Dataverse)\" —\n * https://learn.microsoft.com/en-us/power-apps/developer/data-platform/webapi/perform-conditional-operations-using-web-api\n * (\"Dataverse generates a weakly validating `@odata.etag` property for every entity instance\", and the two 412\n * examples under \"Apply optimistic concurrency\").\n *\n * UNCONFIRMED, and stated rather than hidden: Dataverse documents optimistic concurrency as supported \"on all\n * out-of-box tables enabled for offline sync and all custom tables\" (Microsoft Learn, \"Optimistic concurrency\"), and\n * the SDK refuses a version-checked update on another table (`OptimisticConcurrencyNotEnabled`). What the Web API\n * answers to an `If-Match` on such a table was not measured; a refusal there reaches the caller as a remote refusal.\n *\n * Dataverse also UPSERTS: a `PATCH` to a key that no longer exists creates the row. The write dialect therefore sends\n * `If-Match` on every update (the row's tag, or `*`), which the same page documents as the way to prevent it.\n */\n rowVersionField: ODATA_ENTITY_TAG_CONTROL_INFORMATION,\n addressSlots: [\n {\n slug: 'baseUrl',\n required: true,\n description:\n \"This environment's Web API service root, version included \"\n + '(https://<org>.crm<region>.dynamics.com/api/data/v9.2). The organization URL alone is not '\n + 'enough: entity-set names are appended to the versioned data path.',\n },\n ],\n credentialOffers: [\n {\n kind: SystemOfRecordCredentialKind.OAUTH2_CLIENT_CREDENTIALS_SECRET,\n // spec-cite: Microsoft Learn, \"Microsoft identity platform and the OAuth 2.0 client credentials\n // flow\" — https://learn.microsoft.com/en-us/entra/identity-platform/v2-oauth2-client-creds-grant\n clientAuthentication: SystemOfRecordClientAuthenticationPlacement.REQUEST_BODY,\n tokenLifetimeFallbackSeconds: 900,\n },\n {\n kind: SystemOfRecordCredentialKind.OAUTH2_CLIENT_CREDENTIALS_CERTIFICATE,\n /*\n * UNCONFIRMED, and left so deliberately: Entra's certificate credential is documented as\n * identifying the signing key by an `x5t` thumbprint in the assertion header, and that is what\n * this declares — but the page was not fetched at authoring time, so it is the plan's\n * expectation rather than a quotation (`external-specification-citations.md` §4). An operator\n * meeting `invalid_client` with a certificate credential should read the vendor's assertion\n * format before assuming the engine is wrong.\n */\n assertionHeaderPolicy: SystemOfRecordAssertionHeaderPolicy.X509_THUMBPRINT_DERIVED,\n assertionSigningAlgorithm: SystemOfRecordAssertionSigningAlgorithm.RS256,\n assertionLifetimeSeconds: 300,\n tokenLifetimeFallbackSeconds: 900,\n },\n ],\n};\n"]}

package/dist/esm/microsoft-dynamics-365-business-central.system-of-record.d.ts ADDED Viewed

@@ -0,0 +1,3 @@
+import type { SystemOfRecordVendorFacet } from '@wildo-ai/saas-models/external-data';
+export declare const MicrosoftDynamics365BusinessCentralSystemOfRecordFacet: SystemOfRecordVendorFacet;
+//# sourceMappingURL=microsoft-dynamics-365-business-central.system-of-record.d.ts.map

package/dist/esm/microsoft-dynamics-365-business-central.system-of-record.d.ts.map ADDED Viewed

	@@ -0,0 +1 @@
1	+ {"version":3,"file":"microsoft-dynamics-365-business-central.system-of-record.d.ts","sourceRoot":"","sources":["../../../src/microsoft-dynamics-365-business-central.system-of-record.ts"],"names":[],"mappings":"AA+BA,OAAO,KAAK,EAAE,yBAAyB,EAAE,MAAM,qCAAqC,CAAC;AASrF,eAAO,MAAM,sDAAsD,EAAE,yBA6DpE,CAAC"}

package/dist/esm/microsoft-dynamics-365-business-central.system-of-record.js ADDED Viewed

@@ -0,0 +1,94 @@
+/**
+ * Microsoft Dynamics 365 Business Central, as a SYSTEM OF RECORD.
+ *
+ * Business Central's own API is OData v4, and an application reads it as a registered Entra
+ * application rather than as a person — which is the whole of D12 for this vendor.
+ *
+ * spec-cite: Microsoft Learn, "Use OAuth to Authorize Business Central Web Services" —
+ * https://learn.microsoft.com/en-us/dynamics365/business-central/dev-itpro/webservices/authenticate-web-services-using-oauth
+ *
+ * ## Why `baseUrl` reaches down to the environment and not merely the host
+ *
+ * A Business Central address carries a TENANT and an ENVIRONMENT
+ * (`.../v2.0/<tenant>/<environment>/api/v2.0`), and both are deployment facts: production and
+ * sandbox differ only in that path segment. Putting the whole service root in one slot is what lets
+ * one declaration serve both by pointing at different environments, which is exactly the shape
+ * `systemsOfRecord` exists for.
+ *
+ * ## Its PARTITION is a path segment, and that is why this facet declares none
+ *
+ * Business Central partitions by COMPANY, and a company is addressed as a path segment
+ * (`/companies({id})/customers`) rather than as a filterable field. That is a real difference from
+ * every other vendor here and it has no expression yet: the partition vocabulary is #1058's, and
+ * that slice supports FIELD partitions first. Declaring something now would be declaring a
+ * narrowing that does not happen — which #1055 already refuses for the instance-side `partition`
+ * key, for the same reason.
+ *
+ * So until #1058: an application reading this vendor sees every company its service identity can
+ * see. That is stated here rather than discovered, and it is why the address slot below asks for a
+ * service root that MAY already name a company.
+ */
+import { HttpApiTransportDialect, SystemOfRecordCredentialKind } from '@wildo-ai/saas-models';
+import { ExternalDataIncrementalExtractionMode, ODATA_ENTITY_TAG_CONTROL_INFORMATION, SystemOfRecordAssertionHeaderPolicy, SystemOfRecordAssertionSigningAlgorithm, SystemOfRecordClientAuthenticationPlacement, } from '@wildo-ai/saas-models/external-data';
+export const MicrosoftDynamics365BusinessCentralSystemOfRecordFacet = {
+    vendor: 'microsoft-dynamics-365-business-central',
+    dialects: [HttpApiTransportDialect.ODATA],
+    /*
+     * #1722 — MODIFIED_AT is a plain OData `$filter … ge` on a timestamp property the pipeline declaration names per entity;
+     * whether an entity carries one is the declaration's to say, not the vendor's.
+     */
+    incrementalExtractionModes: [ExternalDataIncrementalExtractionMode.ODATA_MODIFIED_AT],
+    /*
+     * #1726 — Business Central's API entities carry an entity tag, and it REQUIRES `If-Match` on an update: a request
+     * whose tag no longer matches is not applied. The write dialect sends the tag of the row it read first (or `*`) on
+     * every update and delete, so the requirement is always met.
+     *
+     * spec-cite: Microsoft Learn, "Update customers - Business Central" —
+     * https://learn.microsoft.com/en-us/dynamics365/business-central/dev-itpro/api-reference/v2.0/api/dynamics_customer_update
+     * (request header `If-Match`: "Required. When this request header is included and the eTag provided doesn't match
+     * the current tag on the **customers**, the **customers** won't be updated.").
+     *
+     * Writes and the company PARTITION: a Business Central company is a path segment, and this facet declares no
+     * partition (see above) — the vocabulary's PATH_SEGMENT kind is one startup refuses to confine on. A write therefore
+     * lands in whatever company its `baseUrl` or `entityRef` path names — the same reach its reads have, and nothing wider.
+     */
+    rowVersionField: ODATA_ENTITY_TAG_CONTROL_INFORMATION,
+    addressSlots: [
+        {
+            slug: 'baseUrl',
+            required: true,
+            description: 'The API service root for THIS environment, tenant and environment included '
+                + '(https://api.businesscentral.dynamics.com/v2.0/<tenant>/<environment>/api/v2.0). It may '
+                + "already name a company (…/companies(<id>)) — until per-company narrowing exists, that is "
+                + 'the only way to confine a deployment to one.',
+        },
+    ],
+    credentialOffers: [
+        {
+            kind: SystemOfRecordCredentialKind.OAUTH2_CLIENT_CREDENTIALS_SECRET,
+            // Entra's token endpoint accepts both placements; the body form is what its own examples show.
+            // spec-cite: Microsoft Learn, "Microsoft identity platform and the OAuth 2.0 client credentials flow" —
+            // https://learn.microsoft.com/en-us/entra/identity-platform/v2-oauth2-client-creds-grant
+            clientAuthentication: SystemOfRecordClientAuthenticationPlacement.REQUEST_BODY,
+            // Entra's client-credentials answer carries `expires_in`, so this fallback is a floor that is
+            // not expected to be reached rather than a guess at the real lifetime.
+            tokenLifetimeFallbackSeconds: 900,
+        },
+        {
+            kind: SystemOfRecordCredentialKind.OAUTH2_CLIENT_CREDENTIALS_CERTIFICATE,
+            /*
+             * UNCONFIRMED: Entra's certificate credential is documented as identifying the signing key by
+             * an `x5t` thumbprint in the assertion header, and that is what this declares. The page could
+             * not be fetched at authoring time, so this is the plan's expectation rather than a quotation
+             * — `external-specification-citations.md` §4 rather than an invented citation. An operator who
+             * meets `invalid_client` with a certificate credential should read the vendor's assertion
+             * format before assuming the engine is wrong.
+             */
+            assertionHeaderPolicy: SystemOfRecordAssertionHeaderPolicy.X509_THUMBPRINT_DERIVED,
+            assertionSigningAlgorithm: SystemOfRecordAssertionSigningAlgorithm.RS256,
+            assertionLifetimeSeconds: 300,
+            tokenLifetimeFallbackSeconds: 900,
+        },
+    ],
+};
+//# sourceMappingURL=microsoft-dynamics-365-business-central.system-of-record.js.map

package/dist/esm/microsoft-dynamics-365-business-central.system-of-record.js.map ADDED Viewed

@@ -0,0 +1 @@

+ {"version":3,"file":"microsoft-dynamics-365-business-central.system-of-record.js","sourceRoot":"","sources":["../../../src/microsoft-dynamics-365-business-central.system-of-record.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GA6BG;AACH,OAAO,EAAE,uBAAuB,EAAE,4BAA4B,EAAE,MAAM,uBAAuB,CAAC;AAE9F,OAAO,EACL,qCAAqC,EACrC,oCAAoC,EACpC,mCAAmC,EACnC,uCAAuC,EACvC,2CAA2C,GAC5C,MAAM,qCAAqC,CAAC;AAE7C,MAAM,CAAC,MAAM,sDAAsD,GAA8B;IAC/F,MAAM,EAAE,yCAAyC;IACjD,QAAQ,EAAE,CAAC,uBAAuB,CAAC,KAAK,CAAC;IACzC;;;OAGG;IACH,0BAA0B,EAAE,CAAC,qCAAqC,CAAC,iBAAiB,CAAC;IACrF;;;;;;;;;;;;;OAaG;IACH,eAAe,EAAE,oCAAoC;IACrD,YAAY,EAAE;QACZ;YACE,IAAI,EAAE,SAAS;YACf,QAAQ,EAAE,IAAI;YACd,WAAW,EACT,6EAA6E;kBAC3E,0FAA0F;kBAC1F,2FAA2F;kBAC3F,8CAA8C;SACnD;KACF;IACD,gBAAgB,EAAE;QAChB;YACE,IAAI,EAAE,4BAA4B,CAAC,gCAAgC;YACnE,+FAA+F;YAC/F,wGAAwG;YACxG,yFAAyF;YACzF,oBAAoB,EAAE,2CAA2C,CAAC,YAAY;YAC9E,8FAA8F;YAC9F,uEAAuE;YACvE,4BAA4B,EAAE,GAAG;SAClC;QACD;YACE,IAAI,EAAE,4BAA4B,CAAC,qCAAqC;YACxE;;;;;;;eAOG;YACH,qBAAqB,EAAE,mCAAmC,CAAC,uBAAuB;YAClF,yBAAyB,EAAE,uCAAuC,CAAC,KAAK;YACxE,wBAAwB,EAAE,GAAG;YAC7B,4BAA4B,EAAE,GAAG;SAClC;KACF;CACF,CAAC","sourcesContent":["/**\n * Microsoft Dynamics 365 Business Central, as a SYSTEM OF RECORD.\n *\n * Business Central's own API is OData v4, and an application reads it as a registered Entra\n * application rather than as a person — which is the whole of D12 for this vendor.\n *\n * spec-cite: Microsoft Learn, \"Use OAuth to Authorize Business Central Web Services\" —\n * https://learn.microsoft.com/en-us/dynamics365/business-central/dev-itpro/webservices/authenticate-web-services-using-oauth\n *\n * ## Why `baseUrl` reaches down to the environment and not merely the host\n *\n * A Business Central address carries a TENANT and an ENVIRONMENT\n * (`.../v2.0/<tenant>/<environment>/api/v2.0`), and both are deployment facts: production and\n * sandbox differ only in that path segment. Putting the whole service root in one slot is what lets\n * one declaration serve both by pointing at different environments, which is exactly the shape\n * `systemsOfRecord` exists for.\n *\n * ## Its PARTITION is a path segment, and that is why this facet declares none\n *\n * Business Central partitions by COMPANY, and a company is addressed as a path segment\n * (`/companies({id})/customers`) rather than as a filterable field. That is a real difference from\n * every other vendor here and it has no expression yet: the partition vocabulary is #1058's, and\n * that slice supports FIELD partitions first. Declaring something now would be declaring a\n * narrowing that does not happen — which #1055 already refuses for the instance-side `partition`\n * key, for the same reason.\n *\n * So until #1058: an application reading this vendor sees every company its service identity can\n * see. That is stated here rather than discovered, and it is why the address slot below asks for a\n * service root that MAY already name a company.\n */\nimport { HttpApiTransportDialect, SystemOfRecordCredentialKind } from '@wildo-ai/saas-models';\nimport type { SystemOfRecordVendorFacet } from '@wildo-ai/saas-models/external-data';\nimport {\n ExternalDataIncrementalExtractionMode,\n ODATA_ENTITY_TAG_CONTROL_INFORMATION,\n SystemOfRecordAssertionHeaderPolicy,\n SystemOfRecordAssertionSigningAlgorithm,\n SystemOfRecordClientAuthenticationPlacement,\n} from '@wildo-ai/saas-models/external-data';\n\nexport const MicrosoftDynamics365BusinessCentralSystemOfRecordFacet: SystemOfRecordVendorFacet = {\n vendor: 'microsoft-dynamics-365-business-central',\n dialects: [HttpApiTransportDialect.ODATA],\n /*\n * #1722 — MODIFIED_AT is a plain OData `$filter … ge` on a timestamp property the pipeline declaration names per entity;\n * whether an entity carries one is the declaration's to say, not the vendor's.\n */\n incrementalExtractionModes: [ExternalDataIncrementalExtractionMode.ODATA_MODIFIED_AT],\n /*\n * #1726 — Business Central's API entities carry an entity tag, and it REQUIRES `If-Match` on an update: a request\n * whose tag no longer matches is not applied. The write dialect sends the tag of the row it read first (or `*`) on\n * every update and delete, so the requirement is always met.\n *\n * spec-cite: Microsoft Learn, \"Update customers - Business Central\" —\n * https://learn.microsoft.com/en-us/dynamics365/business-central/dev-itpro/api-reference/v2.0/api/dynamics_customer_update\n * (request header `If-Match`: \"Required. When this request header is included and the eTag provided doesn't match\n * the current tag on the **customers**, the **customers** won't be updated.\").\n *\n * Writes and the company PARTITION: a Business Central company is a path segment, and this facet declares no\n * partition (see above) — the vocabulary's PATH_SEGMENT kind is one startup refuses to confine on. A write therefore\n * lands in whatever company its `baseUrl` or `entityRef` path names — the same reach its reads have, and nothing wider.\n */\n rowVersionField: ODATA_ENTITY_TAG_CONTROL_INFORMATION,\n addressSlots: [\n {\n slug: 'baseUrl',\n required: true,\n description:\n 'The API service root for THIS environment, tenant and environment included '\n + '(https://api.businesscentral.dynamics.com/v2.0/<tenant>/<environment>/api/v2.0). It may '\n + \"already name a company (…/companies(<id>)) — until per-company narrowing exists, that is \"\n + 'the only way to confine a deployment to one.',\n },\n ],\n credentialOffers: [\n {\n kind: SystemOfRecordCredentialKind.OAUTH2_CLIENT_CREDENTIALS_SECRET,\n // Entra's token endpoint accepts both placements; the body form is what its own examples show.\n // spec-cite: Microsoft Learn, \"Microsoft identity platform and the OAuth 2.0 client credentials flow\" —\n // https://learn.microsoft.com/en-us/entra/identity-platform/v2-oauth2-client-creds-grant\n clientAuthentication: SystemOfRecordClientAuthenticationPlacement.REQUEST_BODY,\n // Entra's client-credentials answer carries `expires_in`, so this fallback is a floor that is\n // not expected to be reached rather than a guess at the real lifetime.\n tokenLifetimeFallbackSeconds: 900,\n },\n {\n kind: SystemOfRecordCredentialKind.OAUTH2_CLIENT_CREDENTIALS_CERTIFICATE,\n /*\n * UNCONFIRMED: Entra's certificate credential is documented as identifying the signing key by\n * an `x5t` thumbprint in the assertion header, and that is what this declares. The page could\n * not be fetched at authoring time, so this is the plan's expectation rather than a quotation\n * — `external-specification-citations.md` §4 rather than an invented citation. An operator who\n * meets `invalid_client` with a certificate credential should read the vendor's assertion\n * format before assuming the engine is wrong.\n */\n assertionHeaderPolicy: SystemOfRecordAssertionHeaderPolicy.X509_THUMBPRINT_DERIVED,\n assertionSigningAlgorithm: SystemOfRecordAssertionSigningAlgorithm.RS256,\n assertionLifetimeSeconds: 300,\n tokenLifetimeFallbackSeconds: 900,\n },\n ],\n};\n"]}

package/dist/esm/netsuite.system-of-record.d.ts ADDED Viewed

@@ -0,0 +1,3 @@
+import type { SystemOfRecordVendorFacet } from '@wildo-ai/saas-models/external-data';
+export declare const NetsuiteSystemOfRecordFacet: SystemOfRecordVendorFacet;
+//# sourceMappingURL=netsuite.system-of-record.d.ts.map

package/dist/esm/netsuite.system-of-record.d.ts.map ADDED Viewed

	@@ -0,0 +1 @@
1	+ {"version":3,"file":"netsuite.system-of-record.d.ts","sourceRoot":"","sources":["../../../src/netsuite.system-of-record.ts"],"names":[],"mappings":"AAkDA,OAAO,KAAK,EAAE,yBAAyB,EAAE,MAAM,qCAAqC,CAAC;AAMrF,eAAO,MAAM,2BAA2B,EAAE,yBAyBzC,CAAC"}

package/dist/esm/netsuite.system-of-record.js ADDED Viewed

@@ -0,0 +1,77 @@
+/**
+ * Oracle NetSuite, as a SYSTEM OF RECORD.
+ *
+ * spec-cite: Oracle NetSuite, "SuiteQL" —
+ * https://docs.oracle.com/en/cloud/saas/netsuite/ns-online-help/section_156257770590.html
+ *
+ * ## Read through SuiteQL, posted rather than queried
+ *
+ * A collection read is a SuiteQL statement in the BODY of a POST to
+ * `/services/rest/query/v1/suiteql`, paged by `limit` and `offset` QUERY parameters, and the request
+ * requires a `Prefer: transient` header. All three are declared on the binding's operation — the
+ * statement, the paging parameters and the static header — which is what #1293 added.
+ *
+ * The statement-in-a-body shape is why its operation is a POST and Salesforce's is a GET: the
+ * request builder places the STATEMENT by method. Paging is the exception — NetSuite reads it from
+ * the URL even on a POST, so its placement is declared (below).
+ *
+ * ## Its app-only identity is CLIENT AUTHENTICATION, not the assertion grant
+ *
+ * NetSuite's machine-to-machine flow is `grant_type=client_credentials` with a `client_assertion`
+ * (RFC 7523 §2.2) — its documentation states the grant type is *always* `client_credentials`. That
+ * is client AUTHENTICATION by assertion rather than the assertion GRANT, which is Salesforce's, and
+ * the two are separate credential kinds because the token endpoint reads them differently.
+ *
+ * spec-cite: Oracle NetSuite, "OAuth 2.0 Client Credentials Flow" —
+ * https://docs.oracle.com/en/cloud/saas/netsuite/ns-online-help/section_162755359851.html
+ *
+ * The assertion's header carries the key id NetSuite assigns when the certificate is uploaded, which
+ * is why this facet declares the key-id policy and the instance supplies `certificateKeyId`.
+ *
+ * ## What an author gives up, stated rather than discovered
+ *
+ * No declared `sortFields` — a LIST serves the statement's own order, and the ORDER BY belongs in
+ * the SuiteQL. Its paging parameters go in the URL while the statement is in the body, so the
+ * binding declares `pagingParams.placement: 'query-string'` (#1686); placed by method, a POST's
+ * `limit` would land in the body and bound nothing.
+ *
+ * A pipeline walks a declared keyset (#1686), never offsets: the binding's `list` statement declares
+ * `keyset: { keyRemoteField: 'id' }`, and each page is `… WHERE id > <last id> ORDER BY id ASC` with
+ * `limit=<n>&offset=0`, so the 100,000-result offset ceiling is never reached.
+ *
+ * ## The account id is in the ADDRESS, and so is the token endpoint
+ *
+ * Both the REST base URL and the token URL are account-specific
+ * (`https://<accountId>.suitetalk.api.netsuite.com/…`), so neither can be a constant in this file.
+ * They are separate slots because they are separate hosts' worth of a decision: a sandbox account
+ * changes both, and an operator who changed only one would get a working token against the wrong
+ * data.
+ */
+import { HttpApiTransportDialect, SystemOfRecordCredentialKind } from '@wildo-ai/saas-models';
+import { SystemOfRecordAssertionHeaderPolicy, SystemOfRecordAssertionSigningAlgorithm, } from '@wildo-ai/saas-models/external-data';
+export const NetsuiteSystemOfRecordFacet = {
+    vendor: 'netsuite',
+    dialects: [HttpApiTransportDialect.REST_JSON],
+    addressSlots: [
+        {
+            slug: 'baseUrl',
+            required: true,
+            description: "This account's REST services host (https://<accountId>.suitetalk.api.netsuite.com). A "
+                + "binding's path templates are appended to it — the SuiteQL endpoint is one of them.",
+        },
+    ],
+    credentialOffers: [
+        {
+            kind: SystemOfRecordCredentialKind.OAUTH2_CLIENT_CREDENTIALS_CERTIFICATE,
+            // NetSuite locates the signing key by the id it assigned at certificate upload, carried as
+            // `kid` in the assertion's protected header. A thumbprint would identify nothing to it.
+            assertionHeaderPolicy: SystemOfRecordAssertionHeaderPolicy.KEY_ID_SUPPLIED,
+            assertionSigningAlgorithm: SystemOfRecordAssertionSigningAlgorithm.RS256,
+            assertionLifetimeSeconds: 300,
+            // Its token answer states `expires_in` is always 3600, so this fallback is a floor that should
+            // never be reached rather than a guess at the real lifetime.
+            tokenLifetimeFallbackSeconds: 3600,
+        },
+    ],
+};
+//# sourceMappingURL=netsuite.system-of-record.js.map

package/dist/esm/netsuite.system-of-record.js.map ADDED Viewed

@@ -0,0 +1 @@

+ {"version":3,"file":"netsuite.system-of-record.js","sourceRoot":"","sources":["../../../src/netsuite.system-of-record.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GAgDG;AACH,OAAO,EAAE,uBAAuB,EAAE,4BAA4B,EAAE,MAAM,uBAAuB,CAAC;AAE9F,OAAO,EACL,mCAAmC,EACnC,uCAAuC,GACxC,MAAM,qCAAqC,CAAC;AAE7C,MAAM,CAAC,MAAM,2BAA2B,GAA8B;IACpE,MAAM,EAAE,UAAU;IAClB,QAAQ,EAAE,CAAC,uBAAuB,CAAC,SAAS,CAAC;IAC7C,YAAY,EAAE;QACZ;YACE,IAAI,EAAE,SAAS;YACf,QAAQ,EAAE,IAAI;YACd,WAAW,EACT,wFAAwF;kBACtF,oFAAoF;SACzF;KACF;IACD,gBAAgB,EAAE;QAChB;YACE,IAAI,EAAE,4BAA4B,CAAC,qCAAqC;YACxE,2FAA2F;YAC3F,wFAAwF;YACxF,qBAAqB,EAAE,mCAAmC,CAAC,eAAe;YAC1E,yBAAyB,EAAE,uCAAuC,CAAC,KAAK;YACxE,wBAAwB,EAAE,GAAG;YAC7B,+FAA+F;YAC/F,6DAA6D;YAC7D,4BAA4B,EAAE,IAAI;SACnC;KACF;CACF,CAAC","sourcesContent":["/**\n * Oracle NetSuite, as a SYSTEM OF RECORD.\n *\n * spec-cite: Oracle NetSuite, \"SuiteQL\" —\n * https://docs.oracle.com/en/cloud/saas/netsuite/ns-online-help/section_156257770590.html\n *\n * ## Read through SuiteQL, posted rather than queried\n *\n * A collection read is a SuiteQL statement in the BODY of a POST to\n * `/services/rest/query/v1/suiteql`, paged by `limit` and `offset` QUERY parameters, and the request\n * requires a `Prefer: transient` header. All three are declared on the binding's operation — the\n * statement, the paging parameters and the static header — which is what #1293 added.\n *\n * The statement-in-a-body shape is why its operation is a POST and Salesforce's is a GET: the\n * request builder places the STATEMENT by method. Paging is the exception — NetSuite reads it from\n * the URL even on a POST, so its placement is declared (below).\n *\n * ## Its app-only identity is CLIENT AUTHENTICATION, not the assertion grant\n *\n * NetSuite's machine-to-machine flow is `grant_type=client_credentials` with a `client_assertion`\n * (RFC 7523 §2.2) — its documentation states the grant type is *always* `client_credentials`. That\n * is client AUTHENTICATION by assertion rather than the assertion GRANT, which is Salesforce's, and\n * the two are separate credential kinds because the token endpoint reads them differently.\n *\n * spec-cite: Oracle NetSuite, \"OAuth 2.0 Client Credentials Flow\" —\n * https://docs.oracle.com/en/cloud/saas/netsuite/ns-online-help/section_162755359851.html\n *\n * The assertion's header carries the key id NetSuite assigns when the certificate is uploaded, which\n * is why this facet declares the key-id policy and the instance supplies `certificateKeyId`.\n *\n * ## What an author gives up, stated rather than discovered\n *\n * No declared `sortFields` — a LIST serves the statement's own order, and the ORDER BY belongs in\n * the SuiteQL. Its paging parameters go in the URL while the statement is in the body, so the\n * binding declares `pagingParams.placement: 'query-string'` (#1686); placed by method, a POST's\n * `limit` would land in the body and bound nothing.\n *\n * A pipeline walks a declared keyset (#1686), never offsets: the binding's `list` statement declares\n * `keyset: { keyRemoteField: 'id' }`, and each page is `… WHERE id > <last id> ORDER BY id ASC` with\n * `limit=<n>&offset=0`, so the 100,000-result offset ceiling is never reached.\n *\n * ## The account id is in the ADDRESS, and so is the token endpoint\n *\n * Both the REST base URL and the token URL are account-specific\n * (`https://<accountId>.suitetalk.api.netsuite.com/…`), so neither can be a constant in this file.\n * They are separate slots because they are separate hosts' worth of a decision: a sandbox account\n * changes both, and an operator who changed only one would get a working token against the wrong\n * data.\n */\nimport { HttpApiTransportDialect, SystemOfRecordCredentialKind } from '@wildo-ai/saas-models';\nimport type { SystemOfRecordVendorFacet } from '@wildo-ai/saas-models/external-data';\nimport {\n SystemOfRecordAssertionHeaderPolicy,\n SystemOfRecordAssertionSigningAlgorithm,\n} from '@wildo-ai/saas-models/external-data';\n\nexport const NetsuiteSystemOfRecordFacet: SystemOfRecordVendorFacet = {\n vendor: 'netsuite',\n dialects: [HttpApiTransportDialect.REST_JSON],\n addressSlots: [\n {\n slug: 'baseUrl',\n required: true,\n description:\n \"This account's REST services host (https://<accountId>.suitetalk.api.netsuite.com). A \"\n + \"binding's path templates are appended to it — the SuiteQL endpoint is one of them.\",\n },\n ],\n credentialOffers: [\n {\n kind: SystemOfRecordCredentialKind.OAUTH2_CLIENT_CREDENTIALS_CERTIFICATE,\n // NetSuite locates the signing key by the id it assigned at certificate upload, carried as\n // `kid` in the assertion's protected header. A thumbprint would identify nothing to it.\n assertionHeaderPolicy: SystemOfRecordAssertionHeaderPolicy.KEY_ID_SUPPLIED,\n assertionSigningAlgorithm: SystemOfRecordAssertionSigningAlgorithm.RS256,\n assertionLifetimeSeconds: 300,\n // Its token answer states `expires_in` is always 3600, so this fallback is a floor that should\n // never be reached rather than a guess at the real lifetime.\n tokenLifetimeFallbackSeconds: 3600,\n },\n ],\n};\n"]}

package/dist/esm/odata.system-of-record.d.ts ADDED Viewed

@@ -0,0 +1,3 @@
+import type { SystemOfRecordVendorFacet } from '@wildo-ai/saas-models/external-data';
+export declare const OdataSystemOfRecordFacet: SystemOfRecordVendorFacet;
+//# sourceMappingURL=odata.system-of-record.d.ts.map

package/dist/esm/odata.system-of-record.d.ts.map ADDED Viewed

	@@ -0,0 +1 @@
1	+ {"version":3,"file":"odata.system-of-record.d.ts","sourceRoot":"","sources":["../../../src/odata.system-of-record.ts"],"names":[],"mappings":"AA6BA,OAAO,KAAK,EAAE,yBAAyB,EAAE,MAAM,qCAAqC,CAAC;AAQrF,eAAO,MAAM,wBAAwB,EAAE,yBAsEtC,CAAC"}

package/dist/esm/odata.system-of-record.js ADDED Viewed

@@ -0,0 +1,102 @@
+/**
+ * The GENERIC OData v4 facet — for a system of record this catalogue has never heard of.
+ *
+ * Every other facet beside this one names a vendor and encodes what that vendor is known to do.
+ * This one names none, and that is its purpose: an enterprise's own OData v4 service — a bespoke
+ * middleware, an internal ERP surface, a vendor nobody catalogued — is the ordinary case for an
+ * internal tool, and without this facet such a deployment cannot be declared a system of record at
+ * all.
+ *
+ * ## What it can and cannot know
+ *
+ * It declares the widest credential set, because it has no vendor to narrow it to; the INSTANCE
+ * chooses one kind, and boot refuses a kind this list does not offer. It declares OData v4 only,
+ * because that is the one dialect its name asserts. It declares no partition field, because a
+ * generic service has none to declare.
+ *
+ * The consequence an author should know: naming `odata` gives up every vendor-specific correction —
+ * the paging mode, the header a key travels in, the query options a Web API refuses. A vendor with
+ * its own facet is always the better answer when one exists.
+ *
+ * ## `$skip` paging is assumed, and that is a real limitation
+ *
+ * The read-through LIST compiles `$top`/`$skip` (`odata-query-compiler.backend.ts`). OData v4
+ * defines both, so a conformant service serves them — but at least one large implementation
+ * (Dataverse) refuses `$skip` outright, which is why that vendor needs its own facet rather than
+ * this one.
+ * spec-cite: OData Version 4.01 Part 1: Protocol §11.2.6 ($top and $skip system query options).
+ */
+import { HttpApiTransportDialect, SystemOfRecordCredentialKind } from '@wildo-ai/saas-models';
+import { ExternalDataIncrementalExtractionMode, ODATA_ENTITY_TAG_CONTROL_INFORMATION, SystemOfRecordActionCallShape } from '@wildo-ai/saas-models/external-data';
+import { SystemOfRecordAssertionHeaderPolicy, SystemOfRecordAssertionSigningAlgorithm, SystemOfRecordClientAuthenticationPlacement, } from '@wildo-ai/saas-models/external-data';
+export const OdataSystemOfRecordFacet = {
+    vendor: 'odata',
+    dialects: [HttpApiTransportDialect.ODATA],
+    /*
+     * #1722 — both protocol mechanisms, because the generic facet names no vendor and can narrow nothing: a modified-at
+     * filter is plain OData, and change tracking is an optional protocol feature (`Prefer: track-changes`) a service
+     * may or may not offer. A service that does not track changes answers the first delta read without a delta link,
+     * and that pass is refused by name.
+     */
+    incrementalExtractionModes: [ExternalDataIncrementalExtractionMode.ODATA_MODIFIED_AT, ExternalDataIncrementalExtractionMode.ODATA_DELTA_LINK],
+    /*
+     * #1678 — actions are part of the OData v4 PROTOCOL rather than of any one vendor, so the generic facet lists both
+     * invocation forms. Whether a given service exposes a given action is the declaring binding's to know; the engine
+     * only guarantees it calls it the way the protocol defines.
+     *
+     * spec-cite: OData Version 4.01 Part 1: Protocol §11.5.5.1 (Invoking an Action).
+     */
+    actionCallShapes: [SystemOfRecordActionCallShape.ODATA_BOUND_ACTION, SystemOfRecordActionCallShape.ODATA_UNBOUND_ACTION],
+    /*
+     * #1726 — entity tags are part of the OData v4 PROTOCOL: each entity has one that "MUST change when structural
+     * properties or links from that entity have changed", and a write carrying it as `If-Match` is refused with 412 when it
+     * no longer matches. So the generic facet names the tag as its row version, which is what lets a binding declare
+     * `writeConcurrency: VERSION_CHECKED` and have the SERVICE refuse a stale update.
+     *
+     * Whether a given service serves a tag for a given entity set is the declaring binding's to know, exactly as for an
+     * action. A row served without one is refused by name (`WRITE_ROW_VERSION_NOT_SERVED`) rather than compared with
+     * nothing, and a write to such a row still carries `If-Match: *`, which forbids an upsert re-creating it.
+     *
+     * spec-cite: OData Version 4.01 Part 1: Protocol §11.4.1.1 (Use of ETags for Avoiding Update Conflicts) and §8.2.4
+     * (Header If-Match).
+     */
+    rowVersionField: ODATA_ENTITY_TAG_CONTROL_INFORMATION,
+    addressSlots: [
+        {
+            slug: 'baseUrl',
+            required: true,
+            description: "The OData SERVICE ROOT, not the host — the URL an entity-set name is appended to "
+                + '(e.g. https://erp.example/odata/v4). Everything this facet compiles is relative to it.',
+        },
+    ],
+    credentialOffers: [
+        // Bearer is the common shape for a generic service, so it leads. `valuePrefix` carries its own
+        // trailing space: the prefix is concatenated verbatim, which is what lets a vendor that wants a
+        // bare key declare none at all.
+        { kind: SystemOfRecordCredentialKind.API_KEY_HEADER, headerName: 'Authorization', valuePrefix: 'Bearer ' },
+        { kind: SystemOfRecordCredentialKind.BASIC },
+        {
+            kind: SystemOfRecordCredentialKind.OAUTH2_CLIENT_CREDENTIALS_SECRET,
+            // RFC 6749 §2.3.1 says a server MUST support the Basic header and MAY support the body form,
+            // so the header is the one a generic facet can rely on.
+            // spec-cite: RFC 6749 §2.3.1 (Client Password).
+            clientAuthentication: SystemOfRecordClientAuthenticationPlacement.BASIC_HEADER,
+            // RFC 6749 §4.2.2 makes `expires_in` RECOMMENDED rather than required, so a generic facet
+            // needs a fallback. Fifteen minutes: short enough that a server issuing something shorter is
+            // re-minted before it dies, long enough not to mint on every read.
+            // spec-cite: RFC 6749 §4.2.2 (Access Token Response).
+            tokenLifetimeFallbackSeconds: 900,
+        },
+        {
+            kind: SystemOfRecordCredentialKind.OAUTH2_CLIENT_CREDENTIALS_CERTIFICATE,
+            // A generic service cannot be assumed to issue key ids, so the thumbprint policy — derivable
+            // from the certificate the operator already supplies — is the one that needs nothing from the
+            // vendor.
+            assertionHeaderPolicy: SystemOfRecordAssertionHeaderPolicy.X509_THUMBPRINT_DERIVED,
+            assertionSigningAlgorithm: SystemOfRecordAssertionSigningAlgorithm.RS256,
+            assertionLifetimeSeconds: 300,
+            tokenLifetimeFallbackSeconds: 900,
+        },
+    ],
+};
+//# sourceMappingURL=odata.system-of-record.js.map

package/dist/esm/odata.system-of-record.js.map ADDED Viewed

@@ -0,0 +1 @@

+ {"version":3,"file":"odata.system-of-record.js","sourceRoot":"","sources":["../../../src/odata.system-of-record.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;;;;;GA2BG;AACH,OAAO,EAAE,uBAAuB,EAAE,4BAA4B,EAAE,MAAM,uBAAuB,CAAC;AAE9F,OAAO,EAAE,qCAAqC,EAAE,oCAAoC,EAAE,6BAA6B,EAAE,MAAM,qCAAqC,CAAC;AACjK,OAAO,EACL,mCAAmC,EACnC,uCAAuC,EACvC,2CAA2C,GAC5C,MAAM,qCAAqC,CAAC;AAE7C,MAAM,CAAC,MAAM,wBAAwB,GAA8B;IACjE,MAAM,EAAE,OAAO;IACf,QAAQ,EAAE,CAAC,uBAAuB,CAAC,KAAK,CAAC;IACzC;;;;;OAKG;IACH,0BAA0B,EAAE,CAAC,qCAAqC,CAAC,iBAAiB,EAAE,qCAAqC,CAAC,gBAAgB,CAAC;IAC7I;;;;;;OAMG;IACH,gBAAgB,EAAE,CAAC,6BAA6B,CAAC,kBAAkB,EAAE,6BAA6B,CAAC,oBAAoB,CAAC;IACxH;;;;;;;;;;;;OAYG;IACH,eAAe,EAAE,oCAAoC;IACrD,YAAY,EAAE;QACZ;YACE,IAAI,EAAE,SAAS;YACf,QAAQ,EAAE,IAAI;YACd,WAAW,EACT,mFAAmF;kBACjF,wFAAwF;SAC7F;KACF;IACD,gBAAgB,EAAE;QAChB,+FAA+F;QAC/F,gGAAgG;QAChG,gCAAgC;QAChC,EAAE,IAAI,EAAE,4BAA4B,CAAC,cAAc,EAAE,UAAU,EAAE,eAAe,EAAE,WAAW,EAAE,SAAS,EAAE;QAC1G,EAAE,IAAI,EAAE,4BAA4B,CAAC,KAAK,EAAE;QAC5C;YACE,IAAI,EAAE,4BAA4B,CAAC,gCAAgC;YACnE,6FAA6F;YAC7F,wDAAwD;YACxD,gDAAgD;YAChD,oBAAoB,EAAE,2CAA2C,CAAC,YAAY;YAC9E,0FAA0F;YAC1F,6FAA6F;YAC7F,mEAAmE;YACnE,sDAAsD;YACtD,4BAA4B,EAAE,GAAG;SAClC;QACD;YACE,IAAI,EAAE,4BAA4B,CAAC,qCAAqC;YACxE,6FAA6F;YAC7F,8FAA8F;YAC9F,UAAU;YACV,qBAAqB,EAAE,mCAAmC,CAAC,uBAAuB;YAClF,yBAAyB,EAAE,uCAAuC,CAAC,KAAK;YACxE,wBAAwB,EAAE,GAAG;YAC7B,4BAA4B,EAAE,GAAG;SAClC;KACF;CACF,CAAC","sourcesContent":["/**\n * The GENERIC OData v4 facet — for a system of record this catalogue has never heard of.\n *\n * Every other facet beside this one names a vendor and encodes what that vendor is known to do.\n * This one names none, and that is its purpose: an enterprise's own OData v4 service — a bespoke\n * middleware, an internal ERP surface, a vendor nobody catalogued — is the ordinary case for an\n * internal tool, and without this facet such a deployment cannot be declared a system of record at\n * all.\n *\n * ## What it can and cannot know\n *\n * It declares the widest credential set, because it has no vendor to narrow it to; the INSTANCE\n * chooses one kind, and boot refuses a kind this list does not offer. It declares OData v4 only,\n * because that is the one dialect its name asserts. It declares no partition field, because a\n * generic service has none to declare.\n *\n * The consequence an author should know: naming `odata` gives up every vendor-specific correction —\n * the paging mode, the header a key travels in, the query options a Web API refuses. A vendor with\n * its own facet is always the better answer when one exists.\n *\n * ## `$skip` paging is assumed, and that is a real limitation\n *\n * The read-through LIST compiles `$top`/`$skip` (`odata-query-compiler.backend.ts`). OData v4\n * defines both, so a conformant service serves them — but at least one large implementation\n * (Dataverse) refuses `$skip` outright, which is why that vendor needs its own facet rather than\n * this one.\n * spec-cite: OData Version 4.01 Part 1: Protocol §11.2.6 ($top and $skip system query options).\n */\nimport { HttpApiTransportDialect, SystemOfRecordCredentialKind } from '@wildo-ai/saas-models';\nimport type { SystemOfRecordVendorFacet } from '@wildo-ai/saas-models/external-data';\nimport { ExternalDataIncrementalExtractionMode, ODATA_ENTITY_TAG_CONTROL_INFORMATION, SystemOfRecordActionCallShape } from '@wildo-ai/saas-models/external-data';\nimport {\n SystemOfRecordAssertionHeaderPolicy,\n SystemOfRecordAssertionSigningAlgorithm,\n SystemOfRecordClientAuthenticationPlacement,\n} from '@wildo-ai/saas-models/external-data';\n\nexport const OdataSystemOfRecordFacet: SystemOfRecordVendorFacet = {\n vendor: 'odata',\n dialects: [HttpApiTransportDialect.ODATA],\n /*\n * #1722 — both protocol mechanisms, because the generic facet names no vendor and can narrow nothing: a modified-at\n * filter is plain OData, and change tracking is an optional protocol feature (`Prefer: track-changes`) a service\n * may or may not offer. A service that does not track changes answers the first delta read without a delta link,\n * and that pass is refused by name.\n */\n incrementalExtractionModes: [ExternalDataIncrementalExtractionMode.ODATA_MODIFIED_AT, ExternalDataIncrementalExtractionMode.ODATA_DELTA_LINK],\n /*\n * #1678 — actions are part of the OData v4 PROTOCOL rather than of any one vendor, so the generic facet lists both\n * invocation forms. Whether a given service exposes a given action is the declaring binding's to know; the engine\n * only guarantees it calls it the way the protocol defines.\n *\n * spec-cite: OData Version 4.01 Part 1: Protocol §11.5.5.1 (Invoking an Action).\n */\n actionCallShapes: [SystemOfRecordActionCallShape.ODATA_BOUND_ACTION, SystemOfRecordActionCallShape.ODATA_UNBOUND_ACTION],\n /*\n * #1726 — entity tags are part of the OData v4 PROTOCOL: each entity has one that \"MUST change when structural\n * properties or links from that entity have changed\", and a write carrying it as `If-Match` is refused with 412 when it\n * no longer matches. So the generic facet names the tag as its row version, which is what lets a binding declare\n * `writeConcurrency: VERSION_CHECKED` and have the SERVICE refuse a stale update.\n *\n * Whether a given service serves a tag for a given entity set is the declaring binding's to know, exactly as for an\n * action. A row served without one is refused by name (`WRITE_ROW_VERSION_NOT_SERVED`) rather than compared with\n * nothing, and a write to such a row still carries `If-Match: *`, which forbids an upsert re-creating it.\n *\n * spec-cite: OData Version 4.01 Part 1: Protocol §11.4.1.1 (Use of ETags for Avoiding Update Conflicts) and §8.2.4\n * (Header If-Match).\n */\n rowVersionField: ODATA_ENTITY_TAG_CONTROL_INFORMATION,\n addressSlots: [\n {\n slug: 'baseUrl',\n required: true,\n description:\n \"The OData SERVICE ROOT, not the host — the URL an entity-set name is appended to \"\n + '(e.g. https://erp.example/odata/v4). Everything this facet compiles is relative to it.',\n },\n ],\n credentialOffers: [\n // Bearer is the common shape for a generic service, so it leads. `valuePrefix` carries its own\n // trailing space: the prefix is concatenated verbatim, which is what lets a vendor that wants a\n // bare key declare none at all.\n { kind: SystemOfRecordCredentialKind.API_KEY_HEADER, headerName: 'Authorization', valuePrefix: 'Bearer ' },\n { kind: SystemOfRecordCredentialKind.BASIC },\n {\n kind: SystemOfRecordCredentialKind.OAUTH2_CLIENT_CREDENTIALS_SECRET,\n // RFC 6749 §2.3.1 says a server MUST support the Basic header and MAY support the body form,\n // so the header is the one a generic facet can rely on.\n // spec-cite: RFC 6749 §2.3.1 (Client Password).\n clientAuthentication: SystemOfRecordClientAuthenticationPlacement.BASIC_HEADER,\n // RFC 6749 §4.2.2 makes `expires_in` RECOMMENDED rather than required, so a generic facet\n // needs a fallback. Fifteen minutes: short enough that a server issuing something shorter is\n // re-minted before it dies, long enough not to mint on every read.\n // spec-cite: RFC 6749 §4.2.2 (Access Token Response).\n tokenLifetimeFallbackSeconds: 900,\n },\n {\n kind: SystemOfRecordCredentialKind.OAUTH2_CLIENT_CREDENTIALS_CERTIFICATE,\n // A generic service cannot be assumed to issue key ids, so the thumbprint policy — derivable\n // from the certificate the operator already supplies — is the one that needs nothing from the\n // vendor.\n assertionHeaderPolicy: SystemOfRecordAssertionHeaderPolicy.X509_THUMBPRINT_DERIVED,\n assertionSigningAlgorithm: SystemOfRecordAssertionSigningAlgorithm.RS256,\n assertionLifetimeSeconds: 300,\n tokenLifetimeFallbackSeconds: 900,\n },\n ],\n};\n"]}

package/dist/esm/odoo.system-of-record.d.ts ADDED Viewed

@@ -0,0 +1,3 @@
+import type { SystemOfRecordVendorFacet } from '@wildo-ai/saas-models/external-data';
+export declare const OdooSystemOfRecordFacet: SystemOfRecordVendorFacet;
+//# sourceMappingURL=odoo.system-of-record.d.ts.map

package/dist/esm/odoo.system-of-record.d.ts.map ADDED Viewed

	@@ -0,0 +1 @@
1	+ {"version":3,"file":"odoo.system-of-record.d.ts","sourceRoot":"","sources":["../../../src/odoo.system-of-record.ts"],"names":[],"mappings":"AA0DA,OAAO,KAAK,EAAE,yBAAyB,EAAE,MAAM,qCAAqC,CAAC;AASrF,eAAO,MAAM,uBAAuB,EAAE,yBA+DrC,CAAC"}

package/dist/esm/odoo.system-of-record.js ADDED Viewed

@@ -0,0 +1,122 @@
+/**
+ * Odoo, as a SYSTEM OF RECORD — moved here from the engine (#1057 E9).
+ *
+ * ## Why it moved
+ *
+ * #1055 shipped this facet inside `engine/external-connectors-private` by decision, with its own
+ * docstring calling the arrangement temporary and the engine's facet map one that "should shrink to
+ * empty". A vendor facet is a PACKAGE's to own: the engine has no business knowing what an Odoo
+ * needs, any more than it knows what a Salesforce needs, and an engine-resident facet is a vendor
+ * every application carries whether or not it declared one.
+ *
+ * ## Why it is AUTHORED rather than generated
+ *
+ * Odoo has no scraped source — the catalogue record has an `odoo` entry that produced nothing, and
+ * the transposer excludes engine-owned refs by construction. More fundamentally, nothing a scrape
+ * yields could produce this file: a scraped source gives a base URL and an auth kind, and never
+ * "JSON-RPC over `/jsonrpc`, credentials inside the RPC arguments". Dialect and credential kind are
+ * always authored, for every vendor.
+ *
+ * ## Why the slots are what they are
+ *
+ * `baseUrl` is registration-scoped and never credential material: each enterprise runs its own
+ * Odoo, so the URL comes from the deployment environment.
+ *
+ * `database` and `login` are VENDOR address slots even though `ODOO_API_KEY_IN_ARGS` consumes them:
+ * they identify WHICH Odoo database and WHICH user, which stays true under any other credential
+ * kind Odoo might later offer. Only `apiKey` belongs to the kind, and it is declared there.
+ *
+ * ## Its PARTITION is `company_id`, and every part of the declaration was measured
+ *
+ * Odoo holds several COMPANIES inside one database, and `company_id` is on the row. This is the
+ * FIRST vendor facet to declare a partition: #1058 built the whole engine-side
+ * vocabulary and no facet had ever used it, so `partition: true` on an instance was refused by
+ * `PARTITION_NOT_SUPPORTED_BY_VENDOR` for every vendor we ship. The two neighbouring facets that
+ * mention partitioning (Dataverse, Business Central) say only that the vocabulary did not exist
+ * when they were written; Business Central's remains true for a different reason, its partition
+ * being a PATH SEGMENT this engine deliberately cannot confine.
+ *
+ * Measured 2026-09-22 against a REAL Odoo (a 20-company instance), which is what settles the two
+ * fields a reader would otherwise have to guess at:
+ *
+ *   - `valueShape` is `MANY2ONE_PAIR` because a many2one reads back as `[1, "Odoo S.A."]`, never as
+ *     a bare id. A reader taking the whole value matches nothing; one coercing it to a scalar gets
+ *     `"1,Odoo S.A."`. The id is the first element.
+ *   - `codec` is `INTEGER` because the domain is compared by id and Odoo is STRICT about the type:
+ *     `["company_id", "in", [1]]` matches, and `["company_id", "in", ["1"]]` matches NOTHING and
+ *     raises no error. A string key would therefore confine a member to an empty result set while
+ *     looking like a correct narrowing — silence being the dangerous half.
+ *
+ * spec-cite: N/A — both bullets are this repository's own measurement against a live instance, not
+ * a quotation. Odoo's External API documentation states the many2one read shape; it does not state
+ * the domain's type strictness, which is why that half was probed rather than cited.
+ *
+ * An unset `company_id` reads back as `false` (Odoo's spelling of "no value"), which the engine
+ * already reads as the SHARED row that belongs to every partition
+ * (`http-api-partition-confinement.backend.ts:266-273`).
+ */
+import { HttpApiTransportDialect, SystemOfRecordCredentialKind } from '@wildo-ai/saas-models';
+import { SystemOfRecordActionCallShape } from '@wildo-ai/saas-models/external-data';
+import { ExternalDataIncrementalExtractionMode, HttpApiKeyComponentCodec, SystemOfRecordPartitionKind, SystemOfRecordPartitionValueShape, } from '@wildo-ai/saas-models/external-data';
+export const OdooSystemOfRecordFacet = {
+    vendor: 'odoo',
+    dialects: [HttpApiTransportDialect.ODOO_JSONRPC],
+    addressSlots: [
+        {
+            slug: 'baseUrl',
+            required: true,
+            description: "This instance's Odoo URL (e.g. https://mycompany.odoo.com). Deployment-targeted: each "
+                + 'environment names ITS Odoo, and there is no fixed SaaS host to fall back on.',
+        },
+        {
+            slug: 'database',
+            required: true,
+            description: 'The Odoo database name on that instance — the first positional argument of every '
+                + '`execute_kw` call, and part of the `common.authenticate` handshake.',
+        },
+        {
+            slug: 'login',
+            required: true,
+            description: 'The Odoo user login the API key belongs to. `common.authenticate` resolves it to the uid '
+                + 'that every `execute_kw` call then acts as, so it decides what the application can read.',
+        },
+    ],
+    credentialOffers: [{ kind: SystemOfRecordCredentialKind.ODOO_API_KEY_IN_ARGS }],
+    /*
+     * #1678 — Odoo's external API calls ANY public model method through `execute_kw`, so a declared action
+     * (`account.move` `action_post`, `sale.order` `action_confirm`, a model-level `create`) is one call shape.
+     * Odoo offers no idempotency mechanism for such a call, so no Odoo action is ever retry-safe.
+     *
+     * spec-cite: Odoo 18.0 developer documentation, External API — "Calling methods".
+     */
+    actionCallShapes: [SystemOfRecordActionCallShape.ODOO_EXECUTE_KW],
+    partition: {
+        kind: SystemOfRecordPartitionKind.FIELD,
+        remoteField: 'company_id',
+        codec: HttpApiKeyComponentCodec.INTEGER,
+        valueShape: SystemOfRecordPartitionValueShape.MANY2ONE_PAIR,
+    },
+    /*
+     * #1682 — every Odoo model that logs access carries `write_date` ("Last Updated on"), maintained by
+     * the ORM on every write, so a pipeline can read what changed since a watermark. A model declared
+     * `_log_access = False` has no such column; a pipeline over one is refused at its first incremental
+     * page, which names the missing field, rather than here — this facet describes the vendor, not
+     * each of its models.
+     */
+    incrementalExtractionModes: [ExternalDataIncrementalExtractionMode.ODOO_WRITE_DATE],
+    /*
+     * #1724 — the same ORM-maintained `write_date` is the row's VERSION: every `write` stamps it, and no caller can
+     * forget to. It is what a `writeConcurrency: VERSION_CHECKED` binding compares before sending an update.
+     *
+     * Best-effort, and stated where the vendor is described: Odoo 17's `BaseModel.write` takes no precondition, so the
+     * engine can only read the version and then write — two calls, with a race between them. Odoo also SERVES the value
+     * cut to the second (`Datetime.to_string`) while storing microseconds, so two changes inside one second read as one
+     * version. The check narrows the lost-update window; it never closes it.
+     *
+     * spec-cite: Odoo 17.0 `odoo/models.py` — `BaseModel.write(self, vals)` ("Updates all records in ``self`` with the
+     * provided values", no version argument) and `_write` (`vals.setdefault('write_date', self.env.cr.now())`);
+     * `odoo/fields.py` `Datetime.to_string` for the served precision (https://github.com/odoo/odoo/tree/17.0/odoo).
+     */
+    rowVersionField: 'write_date',
+};
+//# sourceMappingURL=odoo.system-of-record.js.map

package/dist/esm/odoo.system-of-record.js.map ADDED Viewed

@@ -0,0 +1 @@

+ {"version":3,"file":"odoo.system-of-record.js","sourceRoot":"","sources":["../../../src/odoo.system-of-record.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GAwDG;AACH,OAAO,EAAE,uBAAuB,EAAE,4BAA4B,EAAE,MAAM,uBAAuB,CAAC;AAE9F,OAAO,EAAE,6BAA6B,EAAE,MAAM,qCAAqC,CAAC;AACpF,OAAO,EACL,qCAAqC,EACrC,wBAAwB,EACxB,2BAA2B,EAC3B,iCAAiC,GAClC,MAAM,qCAAqC,CAAC;AAE7C,MAAM,CAAC,MAAM,uBAAuB,GAA8B;IAChE,MAAM,EAAE,MAAM;IACd,QAAQ,EAAE,CAAC,uBAAuB,CAAC,YAAY,CAAC;IAChD,YAAY,EAAE;QACZ;YACE,IAAI,EAAE,SAAS;YACf,QAAQ,EAAE,IAAI;YACd,WAAW,EACT,wFAAwF;kBACtF,8EAA8E;SACnF;QACD;YACE,IAAI,EAAE,UAAU;YAChB,QAAQ,EAAE,IAAI;YACd,WAAW,EACT,mFAAmF;kBACjF,qEAAqE;SAC1E;QACD;YACE,IAAI,EAAE,OAAO;YACb,QAAQ,EAAE,IAAI;YACd,WAAW,EACT,2FAA2F;kBACzF,yFAAyF;SAC9F;KACF;IACD,gBAAgB,EAAE,CAAC,EAAE,IAAI,EAAE,4BAA4B,CAAC,oBAAoB,EAAE,CAAC;IAC/E;;;;;;OAMG;IACH,gBAAgB,EAAE,CAAC,6BAA6B,CAAC,eAAe,CAAC;IACjE,SAAS,EAAE;QACT,IAAI,EAAE,2BAA2B,CAAC,KAAK;QACvC,WAAW,EAAE,YAAY;QACzB,KAAK,EAAE,wBAAwB,CAAC,OAAO;QACvC,UAAU,EAAE,iCAAiC,CAAC,aAAa;KAC5D;IACD;;;;;;OAMG;IACH,0BAA0B,EAAE,CAAC,qCAAqC,CAAC,eAAe,CAAC;IACnF;;;;;;;;;;;;OAYG;IACH,eAAe,EAAE,YAAY;CAC9B,CAAC","sourcesContent":["/**\n * Odoo, as a SYSTEM OF RECORD — moved here from the engine (#1057 E9).\n *\n * ## Why it moved\n *\n * #1055 shipped this facet inside `engine/external-connectors-private` by decision, with its own\n * docstring calling the arrangement temporary and the engine's facet map one that \"should shrink to\n * empty\". A vendor facet is a PACKAGE's to own: the engine has no business knowing what an Odoo\n * needs, any more than it knows what a Salesforce needs, and an engine-resident facet is a vendor\n * every application carries whether or not it declared one.\n *\n * ## Why it is AUTHORED rather than generated\n *\n * Odoo has no scraped source — the catalogue record has an `odoo` entry that produced nothing, and\n * the transposer excludes engine-owned refs by construction. More fundamentally, nothing a scrape\n * yields could produce this file: a scraped source gives a base URL and an auth kind, and never\n * \"JSON-RPC over `/jsonrpc`, credentials inside the RPC arguments\". Dialect and credential kind are\n * always authored, for every vendor.\n *\n * ## Why the slots are what they are\n *\n * `baseUrl` is registration-scoped and never credential material: each enterprise runs its own\n * Odoo, so the URL comes from the deployment environment.\n *\n * `database` and `login` are VENDOR address slots even though `ODOO_API_KEY_IN_ARGS` consumes them:\n * they identify WHICH Odoo database and WHICH user, which stays true under any other credential\n * kind Odoo might later offer. Only `apiKey` belongs to the kind, and it is declared there.\n *\n * ## Its PARTITION is `company_id`, and every part of the declaration was measured\n *\n * Odoo holds several COMPANIES inside one database, and `company_id` is on the row. This is the\n * FIRST vendor facet to declare a partition: #1058 built the whole engine-side\n * vocabulary and no facet had ever used it, so `partition: true` on an instance was refused by\n * `PARTITION_NOT_SUPPORTED_BY_VENDOR` for every vendor we ship. The two neighbouring facets that\n * mention partitioning (Dataverse, Business Central) say only that the vocabulary did not exist\n * when they were written; Business Central's remains true for a different reason, its partition\n * being a PATH SEGMENT this engine deliberately cannot confine.\n *\n * Measured 2026-09-22 against a REAL Odoo (a 20-company instance), which is what settles the two\n * fields a reader would otherwise have to guess at:\n *\n * - `valueShape` is `MANY2ONE_PAIR` because a many2one reads back as `[1, \"Odoo S.A.\"]`, never as\n * a bare id. A reader taking the whole value matches nothing; one coercing it to a scalar gets\n * `\"1,Odoo S.A.\"`. The id is the first element.\n * - `codec` is `INTEGER` because the domain is compared by id and Odoo is STRICT about the type:\n * `[\"company_id\", \"in\", [1]]` matches, and `[\"company_id\", \"in\", [\"1\"]]` matches NOTHING and\n * raises no error. A string key would therefore confine a member to an empty result set while\n * looking like a correct narrowing — silence being the dangerous half.\n *\n * spec-cite: N/A — both bullets are this repository's own measurement against a live instance, not\n * a quotation. Odoo's External API documentation states the many2one read shape; it does not state\n * the domain's type strictness, which is why that half was probed rather than cited.\n *\n * An unset `company_id` reads back as `false` (Odoo's spelling of \"no value\"), which the engine\n * already reads as the SHARED row that belongs to every partition\n * (`http-api-partition-confinement.backend.ts:266-273`).\n */\nimport { HttpApiTransportDialect, SystemOfRecordCredentialKind } from '@wildo-ai/saas-models';\nimport type { SystemOfRecordVendorFacet } from '@wildo-ai/saas-models/external-data';\nimport { SystemOfRecordActionCallShape } from '@wildo-ai/saas-models/external-data';\nimport {\n ExternalDataIncrementalExtractionMode,\n HttpApiKeyComponentCodec,\n SystemOfRecordPartitionKind,\n SystemOfRecordPartitionValueShape,\n} from '@wildo-ai/saas-models/external-data';\n\nexport const OdooSystemOfRecordFacet: SystemOfRecordVendorFacet = {\n vendor: 'odoo',\n dialects: [HttpApiTransportDialect.ODOO_JSONRPC],\n addressSlots: [\n {\n slug: 'baseUrl',\n required: true,\n description:\n \"This instance's Odoo URL (e.g. https://mycompany.odoo.com). Deployment-targeted: each \"\n + 'environment names ITS Odoo, and there is no fixed SaaS host to fall back on.',\n },\n {\n slug: 'database',\n required: true,\n description:\n 'The Odoo database name on that instance — the first positional argument of every '\n + '`execute_kw` call, and part of the `common.authenticate` handshake.',\n },\n {\n slug: 'login',\n required: true,\n description:\n 'The Odoo user login the API key belongs to. `common.authenticate` resolves it to the uid '\n + 'that every `execute_kw` call then acts as, so it decides what the application can read.',\n },\n ],\n credentialOffers: [{ kind: SystemOfRecordCredentialKind.ODOO_API_KEY_IN_ARGS }],\n /*\n * #1678 — Odoo's external API calls ANY public model method through `execute_kw`, so a declared action\n * (`account.move` `action_post`, `sale.order` `action_confirm`, a model-level `create`) is one call shape.\n * Odoo offers no idempotency mechanism for such a call, so no Odoo action is ever retry-safe.\n *\n * spec-cite: Odoo 18.0 developer documentation, External API — \"Calling methods\".\n */\n actionCallShapes: [SystemOfRecordActionCallShape.ODOO_EXECUTE_KW],\n partition: {\n kind: SystemOfRecordPartitionKind.FIELD,\n remoteField: 'company_id',\n codec: HttpApiKeyComponentCodec.INTEGER,\n valueShape: SystemOfRecordPartitionValueShape.MANY2ONE_PAIR,\n },\n /*\n * #1682 — every Odoo model that logs access carries `write_date` (\"Last Updated on\"), maintained by\n * the ORM on every write, so a pipeline can read what changed since a watermark. A model declared\n * `_log_access = False` has no such column; a pipeline over one is refused at its first incremental\n * page, which names the missing field, rather than here — this facet describes the vendor, not\n * each of its models.\n */\n incrementalExtractionModes: [ExternalDataIncrementalExtractionMode.ODOO_WRITE_DATE],\n /*\n * #1724 — the same ORM-maintained `write_date` is the row's VERSION: every `write` stamps it, and no caller can\n * forget to. It is what a `writeConcurrency: VERSION_CHECKED` binding compares before sending an update.\n *\n * Best-effort, and stated where the vendor is described: Odoo 17's `BaseModel.write` takes no precondition, so the\n * engine can only read the version and then write — two calls, with a race between them. Odoo also SERVES the value\n * cut to the second (`Datetime.to_string`) while storing microseconds, so two changes inside one second read as one\n * version. The check narrows the lost-update window; it never closes it.\n *\n * spec-cite: Odoo 17.0 `odoo/models.py` — `BaseModel.write(self, vals)` (\"Updates all records in ``self`` with the\n * provided values\", no version argument) and `_write` (`vals.setdefault('write_date', self.env.cr.now())`);\n * `odoo/fields.py` `Datetime.to_string` for the served precision (https://github.com/odoo/odoo/tree/17.0/odoo).\n */\n rowVersionField: 'write_date',\n};\n"]}

package/dist/esm/salesforce.system-of-record.d.ts ADDED Viewed

@@ -0,0 +1,3 @@
+import type { SystemOfRecordVendorFacet } from '@wildo-ai/saas-models/external-data';
+export declare const SalesforceSystemOfRecordFacet: SystemOfRecordVendorFacet;
+//# sourceMappingURL=salesforce.system-of-record.d.ts.map

package/dist/esm/salesforce.system-of-record.d.ts.map ADDED Viewed

	@@ -0,0 +1 @@
1	+ {"version":3,"file":"salesforce.system-of-record.d.ts","sourceRoot":"","sources":["../../../src/salesforce.system-of-record.ts"],"names":[],"mappings":"AAoCA,OAAO,KAAK,EAAE,yBAAyB,EAAE,MAAM,qCAAqC,CAAC;AAMrF,eAAO,MAAM,6BAA6B,EAAE,yBA0C3C,CAAC"}

package/dist/esm/salesforce.system-of-record.js ADDED Viewed

@@ -0,0 +1,80 @@
+/**
+ * Salesforce, as a SYSTEM OF RECORD.
+ *
+ * spec-cite: Salesforce Developers, "REST API Developer Guide" —
+ * https://developer.salesforce.com/docs/atlas.en-us.api_rest.meta/api_rest/
+ *
+ * ## Read through SOQL, which is why this is REST_JSON and not a dialect
+ *
+ * A collection read is a SOQL statement at `/services/data/vXX.X/query?q=…`, and a page is followed
+ * by the answer's own `nextRecordsUrl`. Neither is expressible as a set of filter parameters, which
+ * is what #1293 added the statement declaration for. A BINDING supplies the object and its fields;
+ * this facet says the vendor speaks REST_JSON and how its service identity authenticates.
+ *
+ * spec-cite: Salesforce Developers, "SOQL and SOSL Reference" —
+ * https://developer.salesforce.com/docs/atlas.en-us.soql_sosl.meta/soql_sosl/
+ *
+ * ## What an author gives up by choosing it, stated rather than discovered
+ *
+ * **Pipelines walk a declared keyset (#1686).** A Salesforce object feeds a pipeline when the
+ * binding's `list` statement declares `keyset: { keyRemoteField: 'Id' }` and its `cursorPath`
+ * (`nextRecordsUrl`): the engine reads `… WHERE Id > <last Id> ORDER BY Id ASC LIMIT <n>`, follows
+ * the answer's batches to the end of each page, and persists the last Id — never the query locator.
+ * Without a keyset the object is read-through only: offset paging is refused for pipelines.
+ *
+ * **No declared sort.** Resource registration refuses `sortFields` on a REST_JSON binding, so a LIST
+ * serves the statement's own order. A binding may still order inside its SOQL, which is the honest
+ * place for it — the ordering belongs to the query, not to an advertised capability.
+ *
+ * ## The instance URL is an ADDRESS, not an account fact
+ *
+ * An OAuth answer carries `instance_url`, and it is deliberately not read: a system of record is a
+ * deployment the operator names in this environment, and taking its address from a token response
+ * would make the address a property of the credential. Sandbox and production differ by that URL
+ * alone, which is exactly what an address slot is for.
+ */
+import { HttpApiTransportDialect, SystemOfRecordCredentialKind } from '@wildo-ai/saas-models';
+import { SystemOfRecordAssertionSigningAlgorithm, SystemOfRecordClientAuthenticationPlacement, } from '@wildo-ai/saas-models/external-data';
+export const SalesforceSystemOfRecordFacet = {
+    vendor: 'salesforce',
+    dialects: [HttpApiTransportDialect.REST_JSON],
+    addressSlots: [
+        {
+            slug: 'baseUrl',
+            required: true,
+            description: "This org's instance URL (https://<myDomain>.my.salesforce.com). A binding's path templates "
+                + 'are appended to it, so it carries no API version — the version belongs to the operation.',
+        },
+    ],
+    credentialOffers: [
+        {
+            kind: SystemOfRecordCredentialKind.OAUTH2_CLIENT_CREDENTIALS_SECRET,
+            clientAuthentication: SystemOfRecordClientAuthenticationPlacement.REQUEST_BODY,
+            /*
+             * R3's case, and the reason the fallback lives on the OFFER. Salesforce's client-credentials
+             * answer is reported to omit `expires_in` while NetSuite's always carries it — two vendors of
+             * ONE kind, so a per-kind engine constant would have to be wrong for one of them.
+             *
+             * Two hours: a Salesforce session lives far longer, and this is the interval after which the
+             * engine re-mints rather than a claim about the token's real life. Erring short costs a token
+             * request; erring long costs every read until the token dies.
+             */
+            tokenLifetimeFallbackSeconds: 7200,
+        },
+        {
+            /*
+             * The assertion GRANT (RFC 7523 §2.1), which among the vendors surveyed is Salesforce alone —
+             * NetSuite uses the same assertion for client AUTHENTICATION under `client_credentials`. The
+             * two differ in one form field and are two credential kinds for exactly that reason.
+             *
+             * Its `subject` is the integration user the assertion is made FOR, which is why that slot
+             * becomes required under this kind and under no other.
+             */
+            kind: SystemOfRecordCredentialKind.OAUTH2_JWT_BEARER,
+            assertionSigningAlgorithm: SystemOfRecordAssertionSigningAlgorithm.RS256,
+            assertionLifetimeSeconds: 180,
+            tokenLifetimeFallbackSeconds: 7200,
+        },
+    ],
+};
+//# sourceMappingURL=salesforce.system-of-record.js.map

package/dist/esm/salesforce.system-of-record.js.map ADDED Viewed

@@ -0,0 +1 @@

+ {"version":3,"file":"salesforce.system-of-record.js","sourceRoot":"","sources":["../../../src/salesforce.system-of-record.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GAkCG;AACH,OAAO,EAAE,uBAAuB,EAAE,4BAA4B,EAAE,MAAM,uBAAuB,CAAC;AAE9F,OAAO,EACL,uCAAuC,EACvC,2CAA2C,GAC5C,MAAM,qCAAqC,CAAC;AAE7C,MAAM,CAAC,MAAM,6BAA6B,GAA8B;IACtE,MAAM,EAAE,YAAY;IACpB,QAAQ,EAAE,CAAC,uBAAuB,CAAC,SAAS,CAAC;IAC7C,YAAY,EAAE;QACZ;YACE,IAAI,EAAE,SAAS;YACf,QAAQ,EAAE,IAAI;YACd,WAAW,EACT,6FAA6F;kBAC3F,0FAA0F;SAC/F;KACF;IACD,gBAAgB,EAAE;QAChB;YACE,IAAI,EAAE,4BAA4B,CAAC,gCAAgC;YACnE,oBAAoB,EAAE,2CAA2C,CAAC,YAAY;YAC9E;;;;;;;;eAQG;YACH,4BAA4B,EAAE,IAAI;SACnC;QACD;YACE;;;;;;;eAOG;YACH,IAAI,EAAE,4BAA4B,CAAC,iBAAiB;YACpD,yBAAyB,EAAE,uCAAuC,CAAC,KAAK;YACxE,wBAAwB,EAAE,GAAG;YAC7B,4BAA4B,EAAE,IAAI;SACnC;KACF;CACF,CAAC","sourcesContent":["/**\n * Salesforce, as a SYSTEM OF RECORD.\n *\n * spec-cite: Salesforce Developers, \"REST API Developer Guide\" —\n * https://developer.salesforce.com/docs/atlas.en-us.api_rest.meta/api_rest/\n *\n * ## Read through SOQL, which is why this is REST_JSON and not a dialect\n *\n * A collection read is a SOQL statement at `/services/data/vXX.X/query?q=…`, and a page is followed\n * by the answer's own `nextRecordsUrl`. Neither is expressible as a set of filter parameters, which\n * is what #1293 added the statement declaration for. A BINDING supplies the object and its fields;\n * this facet says the vendor speaks REST_JSON and how its service identity authenticates.\n *\n * spec-cite: Salesforce Developers, \"SOQL and SOSL Reference\" —\n * https://developer.salesforce.com/docs/atlas.en-us.soql_sosl.meta/soql_sosl/\n *\n * ## What an author gives up by choosing it, stated rather than discovered\n *\n * **Pipelines walk a declared keyset (#1686).** A Salesforce object feeds a pipeline when the\n * binding's `list` statement declares `keyset: { keyRemoteField: 'Id' }` and its `cursorPath`\n * (`nextRecordsUrl`): the engine reads `… WHERE Id > <last Id> ORDER BY Id ASC LIMIT <n>`, follows\n * the answer's batches to the end of each page, and persists the last Id — never the query locator.\n * Without a keyset the object is read-through only: offset paging is refused for pipelines.\n *\n * **No declared sort.** Resource registration refuses `sortFields` on a REST_JSON binding, so a LIST\n * serves the statement's own order. A binding may still order inside its SOQL, which is the honest\n * place for it — the ordering belongs to the query, not to an advertised capability.\n *\n * ## The instance URL is an ADDRESS, not an account fact\n *\n * An OAuth answer carries `instance_url`, and it is deliberately not read: a system of record is a\n * deployment the operator names in this environment, and taking its address from a token response\n * would make the address a property of the credential. Sandbox and production differ by that URL\n * alone, which is exactly what an address slot is for.\n */\nimport { HttpApiTransportDialect, SystemOfRecordCredentialKind } from '@wildo-ai/saas-models';\nimport type { SystemOfRecordVendorFacet } from '@wildo-ai/saas-models/external-data';\nimport {\n SystemOfRecordAssertionSigningAlgorithm,\n SystemOfRecordClientAuthenticationPlacement,\n} from '@wildo-ai/saas-models/external-data';\n\nexport const SalesforceSystemOfRecordFacet: SystemOfRecordVendorFacet = {\n vendor: 'salesforce',\n dialects: [HttpApiTransportDialect.REST_JSON],\n addressSlots: [\n {\n slug: 'baseUrl',\n required: true,\n description:\n \"This org's instance URL (https://<myDomain>.my.salesforce.com). A binding's path templates \"\n + 'are appended to it, so it carries no API version — the version belongs to the operation.',\n },\n ],\n credentialOffers: [\n {\n kind: SystemOfRecordCredentialKind.OAUTH2_CLIENT_CREDENTIALS_SECRET,\n clientAuthentication: SystemOfRecordClientAuthenticationPlacement.REQUEST_BODY,\n /*\n * R3's case, and the reason the fallback lives on the OFFER. Salesforce's client-credentials\n * answer is reported to omit `expires_in` while NetSuite's always carries it — two vendors of\n * ONE kind, so a per-kind engine constant would have to be wrong for one of them.\n *\n * Two hours: a Salesforce session lives far longer, and this is the interval after which the\n * engine re-mints rather than a claim about the token's real life. Erring short costs a token\n * request; erring long costs every read until the token dies.\n */\n tokenLifetimeFallbackSeconds: 7200,\n },\n {\n /*\n * The assertion GRANT (RFC 7523 §2.1), which among the vendors surveyed is Salesforce alone —\n * NetSuite uses the same assertion for client AUTHENTICATION under `client_credentials`. The\n * two differ in one form field and are two credential kinds for exactly that reason.\n *\n * Its `subject` is the integration user the assertion is made FOR, which is why that slot\n * becomes required under this kind and under no other.\n */\n kind: SystemOfRecordCredentialKind.OAUTH2_JWT_BEARER,\n assertionSigningAlgorithm: SystemOfRecordAssertionSigningAlgorithm.RS256,\n assertionLifetimeSeconds: 180,\n tokenLifetimeFallbackSeconds: 7200,\n },\n ],\n};\n"]}

package/dist/esm/sap-s4hana.system-of-record.d.ts ADDED Viewed

@@ -0,0 +1,3 @@
+import type { SystemOfRecordVendorFacet } from '@wildo-ai/saas-models/external-data';
+export declare const SapS4hanaSystemOfRecordFacet: SystemOfRecordVendorFacet;
+//# sourceMappingURL=sap-s4hana.system-of-record.d.ts.map

package/dist/esm/sap-s4hana.system-of-record.d.ts.map ADDED Viewed

	@@ -0,0 +1 @@
1	+ {"version":3,"file":"sap-s4hana.system-of-record.d.ts","sourceRoot":"","sources":["../../../src/sap-s4hana.system-of-record.ts"],"names":[],"mappings":"AAsDA,OAAO,KAAK,EAAE,yBAAyB,EAAE,MAAM,qCAAqC,CAAC;AAGrF,eAAO,MAAM,4BAA4B,EAAE,yBA4B1C,CAAC"}

package/dist/esm/sap-s4hana.system-of-record.js ADDED Viewed

@@ -0,0 +1,84 @@
+/**
+ * SAP S/4HANA, as a SYSTEM OF RECORD.
+ *
+ * Named `sap-s4hana` rather than `sap-s4hana-cloud`, and that is a measured choice rather than a
+ * preference: `sap-s4hana` already exists as a catalogue-record ref and is the `providerRef` three
+ * OData fixtures in `saas-models` already use. A second spelling would make the same vendor two
+ * vendors, which is what `mergedCatalogueEntries` exists to prevent.
+ *
+ * ## Only BASIC, and the honest reason
+ *
+ * S/4HANA's app-only identity is a COMMUNICATION USER, and SAP's own guidance prefers an X.509
+ * client certificate over a password for one. That preference cannot be honoured here: presenting a
+ * client certificate is a TRANSPORT credential, and the outbound seam carries no channel for one
+ * (#1263). So this facet offers the password half only, and an operator whose communication
+ * arrangement is certificate-based cannot use it yet.
+ *
+ * Stated rather than omitted, because the two failure modes read identically from outside: a vendor
+ * this facet cannot serve and a vendor nobody has authored look the same to an author holding a
+ * refusal.
+ *
+ * spec-cite: N/A — SAP's certificate preference for communication users is recorded as UNCONFIRMED
+ * in epic #1049 §4.6 and is deliberately not quoted here; what is asserted above is only what this
+ * facet does, which is a fact about this file.
+ *
+ * ## OData v2 and v4, one instance per service root (#1687)
+ *
+ * S/4HANA's most-used API surface (`API_BUSINESS_PARTNER`) is OData **v2**, published beside newer v4
+ * services, so this facet speaks both: an instance declares `dialect: ODATA_V2` for a classic Gateway root
+ * (`/sap/opu/odata/sap/<SERVICE>`) and `ODATA` for a v4 root (`/sap/opu/odata4/…`). The binding's dialect
+ * must match its instance's. A system reached over both is two instances, one per root, each with its own
+ * `maxRequestsPerMinute` — the reasoning is at the declaration's `dialect` field.
+ *
+ * A v2 root declared as `ODATA` is still refused BY NAME at the first read, because #1055 forbids a
+ * boot-time probe of the remote and a path heuristic could only ever warn.
+ *
+ * A v2 instance READS only: the engine takes each property's type from the service's `$metadata`, decodes
+ * `/Date(…)/`, decimals and 64-bit integers from their string forms, and a pipeline walks the entity's key
+ * rather than `__next` (v2 promises no stability across a partial listing).
+ *
+ * ## Writes are REFUSED at startup: SAP requires a CSRF-token handshake the engine does not perform (#1726)
+ *
+ * SAP Gateway protects every modifying request with a token: the client first sends a non-modifying request carrying
+ * `X-CSRF-Token: Fetch`, then sends the returned token and the session cookie with the write. The engine's read client
+ * keeps no cookie jar and fetches no token, so every S/4HANA write would be answered `403` — hence
+ * `writePrerequisites`, and a binding opening writes against this vendor is refused at startup
+ * (`WRITE_PREREQUISITE_NOT_SUPPORTED`) instead of failing at its first request.
+ * spec-cite: SAP Help Portal, SAP Gateway Foundation — "Cross-Site Request Forgery Protection"
+ * (https://help.sap.com/saphelp_gateway20sp12/helpdata/en/e6/cae27d5e8d4996add4067280c8714e/frameset.htm).
+ *
+ * No row version is declared either: SAP's OData v4 services may serve entity tags per entity type, and nobody here
+ * has read that for a service this facet would reach. Both are for whoever performs the handshake; proof against a real
+ * service is #1474's.
+ */
+import { HttpApiTransportDialect, SystemOfRecordCredentialKind } from '@wildo-ai/saas-models';
+import { ExternalDataIncrementalExtractionMode, SystemOfRecordWritePrerequisite } from '@wildo-ai/saas-models/external-data';
+export const SapS4hanaSystemOfRecordFacet = {
+    vendor: 'sap-s4hana',
+    dialects: [HttpApiTransportDialect.ODATA, HttpApiTransportDialect.ODATA_V2],
+    /*
+     * #1722 — v4 roots only (the mode is spoken over ODATA). MODIFIED_AT is a plain OData `$filter … ge` on a timestamp property the pipeline declaration names per entity;
+     * whether an entity carries one is the declaration's to say, not the vendor's.
+     */
+    incrementalExtractionModes: [ExternalDataIncrementalExtractionMode.ODATA_MODIFIED_AT],
+    // #1726 — see "Writes are REFUSED at startup" above.
+    writePrerequisites: [SystemOfRecordWritePrerequisite.CSRF_TOKEN_HANDSHAKE],
+    addressSlots: [
+        {
+            slug: 'baseUrl',
+            required: true,
+            description: 'The OData service root for this instance: https://<host>/sap/opu/odata4/sap/<service>/… for a v4 service '
+                + '(declare dialect ODATA), or https://<host>/sap/opu/odata/sap/<SERVICE> for a classic v2 Gateway service '
+                + '(declare dialect ODATA_V2). One root per instance; a system serving both is two instances.',
+        },
+    ],
+    credentialOffers: [
+        /*
+         * The communication user's password. Its USERNAME is an address slot rather than a secret — it
+         * names WHICH user rather than proving anything — and it may not contain `:`, which RFC 7617
+         * makes the delimiter; boot refuses one that does.
+         */
+        { kind: SystemOfRecordCredentialKind.BASIC },
+    ],
+};
+//# sourceMappingURL=sap-s4hana.system-of-record.js.map

package/dist/esm/sap-s4hana.system-of-record.js.map ADDED Viewed

@@ -0,0 +1 @@

+ {"version":3,"file":"sap-s4hana.system-of-record.js","sourceRoot":"","sources":["../../../src/sap-s4hana.system-of-record.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GAoDG;AACH,OAAO,EAAE,uBAAuB,EAAE,4BAA4B,EAAE,MAAM,uBAAuB,CAAC;AAE9F,OAAO,EAAE,qCAAqC,EAAE,+BAA+B,EAAE,MAAM,qCAAqC,CAAC;AAE7H,MAAM,CAAC,MAAM,4BAA4B,GAA8B;IACrE,MAAM,EAAE,YAAY;IACpB,QAAQ,EAAE,CAAC,uBAAuB,CAAC,KAAK,EAAE,uBAAuB,CAAC,QAAQ,CAAC;IAC3E;;;OAGG;IACH,0BAA0B,EAAE,CAAC,qCAAqC,CAAC,iBAAiB,CAAC;IACrF,qDAAqD;IACrD,kBAAkB,EAAE,CAAC,+BAA+B,CAAC,oBAAoB,CAAC;IAC1E,YAAY,EAAE;QACZ;YACE,IAAI,EAAE,SAAS;YACf,QAAQ,EAAE,IAAI;YACd,WAAW,EACT,2GAA2G;kBACzG,0GAA0G;kBAC1G,4FAA4F;SACjG;KACF;IACD,gBAAgB,EAAE;QAChB;;;;WAIG;QACH,EAAE,IAAI,EAAE,4BAA4B,CAAC,KAAK,EAAE;KAC7C;CACF,CAAC","sourcesContent":["/**\n * SAP S/4HANA, as a SYSTEM OF RECORD.\n *\n * Named `sap-s4hana` rather than `sap-s4hana-cloud`, and that is a measured choice rather than a\n * preference: `sap-s4hana` already exists as a catalogue-record ref and is the `providerRef` three\n * OData fixtures in `saas-models` already use. A second spelling would make the same vendor two\n * vendors, which is what `mergedCatalogueEntries` exists to prevent.\n *\n * ## Only BASIC, and the honest reason\n *\n * S/4HANA's app-only identity is a COMMUNICATION USER, and SAP's own guidance prefers an X.509\n * client certificate over a password for one. That preference cannot be honoured here: presenting a\n * client certificate is a TRANSPORT credential, and the outbound seam carries no channel for one\n * (#1263). So this facet offers the password half only, and an operator whose communication\n * arrangement is certificate-based cannot use it yet.\n *\n * Stated rather than omitted, because the two failure modes read identically from outside: a vendor\n * this facet cannot serve and a vendor nobody has authored look the same to an author holding a\n * refusal.\n *\n * spec-cite: N/A — SAP's certificate preference for communication users is recorded as UNCONFIRMED\n * in epic #1049 §4.6 and is deliberately not quoted here; what is asserted above is only what this\n * facet does, which is a fact about this file.\n *\n * ## OData v2 and v4, one instance per service root (#1687)\n *\n * S/4HANA's most-used API surface (`API_BUSINESS_PARTNER`) is OData **v2**, published beside newer v4\n * services, so this facet speaks both: an instance declares `dialect: ODATA_V2` for a classic Gateway root\n * (`/sap/opu/odata/sap/<SERVICE>`) and `ODATA` for a v4 root (`/sap/opu/odata4/…`). The binding's dialect\n * must match its instance's. A system reached over both is two instances, one per root, each with its own\n * `maxRequestsPerMinute` — the reasoning is at the declaration's `dialect` field.\n *\n * A v2 root declared as `ODATA` is still refused BY NAME at the first read, because #1055 forbids a\n * boot-time probe of the remote and a path heuristic could only ever warn.\n *\n * A v2 instance READS only: the engine takes each property's type from the service's `$metadata`, decodes\n * `/Date(…)/`, decimals and 64-bit integers from their string forms, and a pipeline walks the entity's key\n * rather than `__next` (v2 promises no stability across a partial listing).\n *\n * ## Writes are REFUSED at startup: SAP requires a CSRF-token handshake the engine does not perform (#1726)\n *\n * SAP Gateway protects every modifying request with a token: the client first sends a non-modifying request carrying\n * `X-CSRF-Token: Fetch`, then sends the returned token and the session cookie with the write. The engine's read client\n * keeps no cookie jar and fetches no token, so every S/4HANA write would be answered `403` — hence\n * `writePrerequisites`, and a binding opening writes against this vendor is refused at startup\n * (`WRITE_PREREQUISITE_NOT_SUPPORTED`) instead of failing at its first request.\n * spec-cite: SAP Help Portal, SAP Gateway Foundation — \"Cross-Site Request Forgery Protection\"\n * (https://help.sap.com/saphelp_gateway20sp12/helpdata/en/e6/cae27d5e8d4996add4067280c8714e/frameset.htm).\n *\n * No row version is declared either: SAP's OData v4 services may serve entity tags per entity type, and nobody here\n * has read that for a service this facet would reach. Both are for whoever performs the handshake; proof against a real\n * service is #1474's.\n */\nimport { HttpApiTransportDialect, SystemOfRecordCredentialKind } from '@wildo-ai/saas-models';\nimport type { SystemOfRecordVendorFacet } from '@wildo-ai/saas-models/external-data';\nimport { ExternalDataIncrementalExtractionMode, SystemOfRecordWritePrerequisite } from '@wildo-ai/saas-models/external-data';\n\nexport const SapS4hanaSystemOfRecordFacet: SystemOfRecordVendorFacet = {\n vendor: 'sap-s4hana',\n dialects: [HttpApiTransportDialect.ODATA, HttpApiTransportDialect.ODATA_V2],\n /*\n * #1722 — v4 roots only (the mode is spoken over ODATA). MODIFIED_AT is a plain OData `$filter … ge` on a timestamp property the pipeline declaration names per entity;\n * whether an entity carries one is the declaration's to say, not the vendor's.\n */\n incrementalExtractionModes: [ExternalDataIncrementalExtractionMode.ODATA_MODIFIED_AT],\n // #1726 — see \"Writes are REFUSED at startup\" above.\n writePrerequisites: [SystemOfRecordWritePrerequisite.CSRF_TOKEN_HANDSHAKE],\n addressSlots: [\n {\n slug: 'baseUrl',\n required: true,\n description:\n 'The OData service root for this instance: https://<host>/sap/opu/odata4/sap/<service>/… for a v4 service '\n + '(declare dialect ODATA), or https://<host>/sap/opu/odata/sap/<SERVICE> for a classic v2 Gateway service '\n + '(declare dialect ODATA_V2). One root per instance; a system serving both is two instances.',\n },\n ],\n credentialOffers: [\n /*\n * The communication user's password. Its USERNAME is an address slot rather than a secret — it\n * names WHICH user rather than proving anything — and it may not contain `:`, which RFC 7617\n * makes the delimiter; boot refuses one that does.\n */\n { kind: SystemOfRecordCredentialKind.BASIC },\n ],\n};\n"]}

package/dist/esm/systems-of-record.exports.d.ts ADDED Viewed

@@ -0,0 +1,78 @@
+/**
+ * The framework's SYSTEM-OF-RECORD FACETS — the public entrypoint behind
+ * `@wildo-ai/systems-of-record/systems-of-record` (#1057, moved into its own library by #2013).
+ *
+ * ## Why a library of its own
+ *
+ * These facets were born inside the transposed provider catalogue (now archived under `_code_archive/providers/`),
+ * under an underscore folder that its regeneration skipped. That kept them alive and nothing more: a system of
+ * record is not a provider an application CALLS, it is a remote system that is the authoritative store
+ * of some of the application's own resources — declared under `systemsOfRecord`, reached through its
+ * instance's service identity only, and never copied into an application (#1049). Paul decided on
+ * 2026-09-29 that the lane is delivered as a classical library, and the catalogue was archived
+ * (#2012, #2019), so the facets moved here.
+ *
+ * It is an OPT-IN framework package (`optInFrameworkPackages`, #1836): an application links it only by
+ * declaring it, and `wildo config sync` declares it on the backend the moment `systemsOfRecord` is
+ * non-empty. An application that declares no system of record never receives it.
+ *
+ * Discovery admits this package's `./systems-of-record` by its exact NAME; any other facet module is
+ * admitted only when an instance opts into it through `facetAugmentations`. The engine code that reads
+ * a facet (dialects, pipelines, actions) stays in `@wildo-ai/saas-backend-lib`.
+ *
+ * ## Why ONE subpath rather than one per vendor
+ *
+ * The first plan called for a subpath per vendor, `./<ref>/facet`. It does not survive contact with
+ * what a facet IS: every field that makes a facet a facet — the dialect, the credential kinds, the
+ * partition — is AUTHORED vendor knowledge, and a facet is inert data with no transitive graph. One
+ * module holding a record of seven object literals is the whole of it.
+ *
+ * ## Why a flat record rather than a loader map
+ *
+ * The engine's map — the one this replaces — used thunks (`vendor -> () => import(...)`) so nothing
+ * was evaluated until a vendor was asked for. That cost is real when the map sits in an engine
+ * everybody loads. Here it does not apply: this module is reached only when an application declared a
+ * system of record at all.
+ *
+ * ## The export NAMES are the facet-module contract
+ *
+ * `PROVIDER_CATALOGUE_SYSTEM_OF_RECORD_FACETS` and its siblings keep the names they had in the
+ * catalogue because they are what `SYSTEM_OF_RECORD_FACET_RECORD_EXPORT` (saas-models) names, and every
+ * augmentation package exports its record under the matching `…_FACET_AUGMENTATIONS`. Renaming them is a
+ * contract change for every facet module, not a tidy-up of this file.
+ *
+ * ## Adding one
+ *
+ * Author `<vendor>.system-of-record.ts` beside this file and add its row below. The key and the
+ * facet's own `vendor` must agree; `systems-of-record.exports.test.ts` asserts it, because a
+ * hand-written key beside a declared id is exactly the shape that drifts.
+ */
+import type { SystemOfRecordVendorFacet } from '@wildo-ai/saas-models/external-data';
+/**
+ * Every vendor the framework can serve as a system of record, keyed by the id an instance names.
+ *
+ * Far fewer vendors than there are providers, because being reachable over HTTP is not the same as
+ * being a deployment an application reads its own rows out of. A vendor absent from here is not
+ * refused by this record — it is a vendor the framework does not describe; the generic `odata` facet
+ * serves any OData v4 service.
+ */
+export declare const PROVIDER_CATALOGUE_SYSTEM_OF_RECORD_FACETS: Readonly<Record<string, SystemOfRecordVendorFacet>>;
+/**
+ * Vendor ids that are ANOTHER vendor's, and which one — so a refusal can point rather than just say no.
+ *
+ * Not misspellings. Each of these is a real provider id, and an author naming one has made a
+ * reasonable mistake: the provider catalogue held `microsoft-dataverse`,
+ * `microsoft-dynamics-365` and `microsoft-dynamics-crm` as three separate connector refs, and they
+ * are three names for ONE Web API. Only one of them can carry the facet, and a refusal that says
+ * "no facet" without saying which sibling has it leaves the author to guess between the other two.
+ *
+ * Lives HERE rather than in the engine for the reason the facets do: which vendor ids are the same
+ * product is vendor knowledge, and adding a vendor tomorrow adds its aliases in the same edit.
+ *
+ * Every value MUST be a key of the facet record above — asserted by `systems-of-record.exports.test.ts`,
+ * because an alias pointing at a vendor that has no facet sends the author from one refusal to another.
+ */
+export declare const PROVIDER_CATALOGUE_SYSTEM_OF_RECORD_VENDOR_ALIASES: Readonly<Record<string, string>>;
+/** The vendor ids above, sorted — what a sync-time discovery records without loading a facet's shape. */
+export declare const PROVIDER_CATALOGUE_SYSTEM_OF_RECORD_VENDORS: readonly string[];
+//# sourceMappingURL=systems-of-record.exports.d.ts.map

package/dist/esm/systems-of-record.exports.d.ts.map ADDED Viewed

@@ -0,0 +1 @@

+ {"version":3,"file":"systems-of-record.exports.d.ts","sourceRoot":"","sources":["../../../src/systems-of-record.exports.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GAgDG;AACH,OAAO,KAAK,EAAE,yBAAyB,EAAE,MAAM,qCAAqC,CAAC;AAUrF;;;;;;;GAOG;AACH,eAAO,MAAM,0CAA0C,EAAE,QAAQ,CAAC,MAAM,CAAC,MAAM,EAAE,yBAAyB,CAAC,CAQ1G,CAAC;AAEF;;;;;;;;;;;;;;GAcG;AACH,eAAO,MAAM,kDAAkD,EAAE,QAAQ,CAAC,MAAM,CAAC,MAAM,EAAE,MAAM,CAAC,CAG/F,CAAC;AAEF,yGAAyG;AACzG,eAAO,MAAM,2CAA2C,EAAE,SAAS,MAAM,EACT,CAAC"}

package/dist/esm/systems-of-record.exports.js ADDED Viewed

@@ -0,0 +1,46 @@
+import { MicrosoftDataverseSystemOfRecordFacet } from './microsoft-dataverse.system-of-record.js';
+import { MicrosoftDynamics365BusinessCentralSystemOfRecordFacet } from './microsoft-dynamics-365-business-central.system-of-record.js';
+import { NetsuiteSystemOfRecordFacet } from './netsuite.system-of-record.js';
+import { OdataSystemOfRecordFacet } from './odata.system-of-record.js';
+import { OdooSystemOfRecordFacet } from './odoo.system-of-record.js';
+import { SalesforceSystemOfRecordFacet } from './salesforce.system-of-record.js';
+import { SapS4hanaSystemOfRecordFacet } from './sap-s4hana.system-of-record.js';
+/**
+ * Every vendor the framework can serve as a system of record, keyed by the id an instance names.
+ *
+ * Far fewer vendors than there are providers, because being reachable over HTTP is not the same as
+ * being a deployment an application reads its own rows out of. A vendor absent from here is not
+ * refused by this record — it is a vendor the framework does not describe; the generic `odata` facet
+ * serves any OData v4 service.
+ */
+export const PROVIDER_CATALOGUE_SYSTEM_OF_RECORD_FACETS = {
+    'microsoft-dataverse': MicrosoftDataverseSystemOfRecordFacet,
+    'microsoft-dynamics-365-business-central': MicrosoftDynamics365BusinessCentralSystemOfRecordFacet,
+    netsuite: NetsuiteSystemOfRecordFacet,
+    odata: OdataSystemOfRecordFacet,
+    odoo: OdooSystemOfRecordFacet,
+    salesforce: SalesforceSystemOfRecordFacet,
+    'sap-s4hana': SapS4hanaSystemOfRecordFacet,
+};
+/**
+ * Vendor ids that are ANOTHER vendor's, and which one — so a refusal can point rather than just say no.
+ *
+ * Not misspellings. Each of these is a real provider id, and an author naming one has made a
+ * reasonable mistake: the provider catalogue held `microsoft-dataverse`,
+ * `microsoft-dynamics-365` and `microsoft-dynamics-crm` as three separate connector refs, and they
+ * are three names for ONE Web API. Only one of them can carry the facet, and a refusal that says
+ * "no facet" without saying which sibling has it leaves the author to guess between the other two.
+ *
+ * Lives HERE rather than in the engine for the reason the facets do: which vendor ids are the same
+ * product is vendor knowledge, and adding a vendor tomorrow adds its aliases in the same edit.
+ *
+ * Every value MUST be a key of the facet record above — asserted by `systems-of-record.exports.test.ts`,
+ * because an alias pointing at a vendor that has no facet sends the author from one refusal to another.
+ */
+export const PROVIDER_CATALOGUE_SYSTEM_OF_RECORD_VENDOR_ALIASES = {
+    'microsoft-dynamics-365': 'microsoft-dataverse',
+    'microsoft-dynamics-crm': 'microsoft-dataverse',
+};
+/** The vendor ids above, sorted — what a sync-time discovery records without loading a facet's shape. */
+export const PROVIDER_CATALOGUE_SYSTEM_OF_RECORD_VENDORS = Object.keys(PROVIDER_CATALOGUE_SYSTEM_OF_RECORD_FACETS).sort();
+//# sourceMappingURL=systems-of-record.exports.js.map

package/dist/esm/systems-of-record.exports.js.map ADDED Viewed

@@ -0,0 +1 @@

+ {"version":3,"file":"systems-of-record.exports.js","sourceRoot":"","sources":["../../../src/systems-of-record.exports.ts"],"names":[],"mappings":"AAmDA,OAAO,EAAE,qCAAqC,EAAE,MAAM,wCAAwC,CAAC;AAC/F,OAAO,EAAE,sDAAsD,EAAE,MAAM,4DAA4D,CAAC;AACpI,OAAO,EAAE,2BAA2B,EAAE,MAAM,6BAA6B,CAAC;AAC1E,OAAO,EAAE,wBAAwB,EAAE,MAAM,0BAA0B,CAAC;AACpE,OAAO,EAAE,uBAAuB,EAAE,MAAM,yBAAyB,CAAC;AAClE,OAAO,EAAE,6BAA6B,EAAE,MAAM,+BAA+B,CAAC;AAC9E,OAAO,EAAE,4BAA4B,EAAE,MAAM,+BAA+B,CAAC;AAE7E;;;;;;;GAOG;AACH,MAAM,CAAC,MAAM,0CAA0C,GAAwD;IAC7G,qBAAqB,EAAE,qCAAqC;IAC5D,yCAAyC,EAAE,sDAAsD;IACjG,QAAQ,EAAE,2BAA2B;IACrC,KAAK,EAAE,wBAAwB;IAC/B,IAAI,EAAE,uBAAuB;IAC7B,UAAU,EAAE,6BAA6B;IACzC,YAAY,EAAE,4BAA4B;CAC3C,CAAC;AAEF;;;;;;;;;;;;;;GAcG;AACH,MAAM,CAAC,MAAM,kDAAkD,GAAqC;IAClG,wBAAwB,EAAE,qBAAqB;IAC/C,wBAAwB,EAAE,qBAAqB;CAChD,CAAC;AAEF,yGAAyG;AACzG,MAAM,CAAC,MAAM,2CAA2C,GACtD,MAAM,CAAC,IAAI,CAAC,0CAA0C,CAAC,CAAC,IAAI,EAAE,CAAC","sourcesContent":["/**\n * The framework's SYSTEM-OF-RECORD FACETS — the public entrypoint behind\n * `@wildo-ai/systems-of-record/systems-of-record` (#1057, moved into its own library by #2013).\n *\n * ## Why a library of its own\n *\n * These facets were born inside the transposed provider catalogue (now archived under `_code_archive/providers/`),\n * under an underscore folder that its regeneration skipped. That kept them alive and nothing more: a system of\n * record is not a provider an application CALLS, it is a remote system that is the authoritative store\n * of some of the application's own resources — declared under `systemsOfRecord`, reached through its\n * instance's service identity only, and never copied into an application (#1049). Paul decided on\n * 2026-09-29 that the lane is delivered as a classical library, and the catalogue was archived\n * (#2012, #2019), so the facets moved here.\n *\n * It is an OPT-IN framework package (`optInFrameworkPackages`, #1836): an application links it only by\n * declaring it, and `wildo config sync` declares it on the backend the moment `systemsOfRecord` is\n * non-empty. An application that declares no system of record never receives it.\n *\n * Discovery admits this package's `./systems-of-record` by its exact NAME; any other facet module is\n * admitted only when an instance opts into it through `facetAugmentations`. The engine code that reads\n * a facet (dialects, pipelines, actions) stays in `@wildo-ai/saas-backend-lib`.\n *\n * ## Why ONE subpath rather than one per vendor\n *\n * The first plan called for a subpath per vendor, `./<ref>/facet`. It does not survive contact with\n * what a facet IS: every field that makes a facet a facet — the dialect, the credential kinds, the\n * partition — is AUTHORED vendor knowledge, and a facet is inert data with no transitive graph. One\n * module holding a record of seven object literals is the whole of it.\n *\n * ## Why a flat record rather than a loader map\n *\n * The engine's map — the one this replaces — used thunks (`vendor -> () => import(...)`) so nothing\n * was evaluated until a vendor was asked for. That cost is real when the map sits in an engine\n * everybody loads. Here it does not apply: this module is reached only when an application declared a\n * system of record at all.\n *\n * ## The export NAMES are the facet-module contract\n *\n * `PROVIDER_CATALOGUE_SYSTEM_OF_RECORD_FACETS` and its siblings keep the names they had in the\n * catalogue because they are what `SYSTEM_OF_RECORD_FACET_RECORD_EXPORT` (saas-models) names, and every\n * augmentation package exports its record under the matching `…_FACET_AUGMENTATIONS`. Renaming them is a\n * contract change for every facet module, not a tidy-up of this file.\n *\n * ## Adding one\n *\n * Author `<vendor>.system-of-record.ts` beside this file and add its row below. The key and the\n * facet's own `vendor` must agree; `systems-of-record.exports.test.ts` asserts it, because a\n * hand-written key beside a declared id is exactly the shape that drifts.\n */\nimport type { SystemOfRecordVendorFacet } from '@wildo-ai/saas-models/external-data';\n\nimport { MicrosoftDataverseSystemOfRecordFacet } from './microsoft-dataverse.system-of-record';\nimport { MicrosoftDynamics365BusinessCentralSystemOfRecordFacet } from './microsoft-dynamics-365-business-central.system-of-record';\nimport { NetsuiteSystemOfRecordFacet } from './netsuite.system-of-record';\nimport { OdataSystemOfRecordFacet } from './odata.system-of-record';\nimport { OdooSystemOfRecordFacet } from './odoo.system-of-record';\nimport { SalesforceSystemOfRecordFacet } from './salesforce.system-of-record';\nimport { SapS4hanaSystemOfRecordFacet } from './sap-s4hana.system-of-record';\n\n/**\n * Every vendor the framework can serve as a system of record, keyed by the id an instance names.\n *\n * Far fewer vendors than there are providers, because being reachable over HTTP is not the same as\n * being a deployment an application reads its own rows out of. A vendor absent from here is not\n * refused by this record — it is a vendor the framework does not describe; the generic `odata` facet\n * serves any OData v4 service.\n */\nexport const PROVIDER_CATALOGUE_SYSTEM_OF_RECORD_FACETS: Readonly<Record<string, SystemOfRecordVendorFacet>> = {\n 'microsoft-dataverse': MicrosoftDataverseSystemOfRecordFacet,\n 'microsoft-dynamics-365-business-central': MicrosoftDynamics365BusinessCentralSystemOfRecordFacet,\n netsuite: NetsuiteSystemOfRecordFacet,\n odata: OdataSystemOfRecordFacet,\n odoo: OdooSystemOfRecordFacet,\n salesforce: SalesforceSystemOfRecordFacet,\n 'sap-s4hana': SapS4hanaSystemOfRecordFacet,\n};\n\n/**\n * Vendor ids that are ANOTHER vendor's, and which one — so a refusal can point rather than just say no.\n *\n * Not misspellings. Each of these is a real provider id, and an author naming one has made a\n * reasonable mistake: the provider catalogue held `microsoft-dataverse`,\n * `microsoft-dynamics-365` and `microsoft-dynamics-crm` as three separate connector refs, and they\n * are three names for ONE Web API. Only one of them can carry the facet, and a refusal that says\n * \"no facet\" without saying which sibling has it leaves the author to guess between the other two.\n *\n * Lives HERE rather than in the engine for the reason the facets do: which vendor ids are the same\n * product is vendor knowledge, and adding a vendor tomorrow adds its aliases in the same edit.\n *\n * Every value MUST be a key of the facet record above — asserted by `systems-of-record.exports.test.ts`,\n * because an alias pointing at a vendor that has no facet sends the author from one refusal to another.\n */\nexport const PROVIDER_CATALOGUE_SYSTEM_OF_RECORD_VENDOR_ALIASES: Readonly<Record<string, string>> = {\n 'microsoft-dynamics-365': 'microsoft-dataverse',\n 'microsoft-dynamics-crm': 'microsoft-dataverse',\n};\n\n/** The vendor ids above, sorted — what a sync-time discovery records without loading a facet's shape. */\nexport const PROVIDER_CATALOGUE_SYSTEM_OF_RECORD_VENDORS: readonly string[] =\n Object.keys(PROVIDER_CATALOGUE_SYSTEM_OF_RECORD_FACETS).sort();\n"]}

package/package.json ADDED Viewed

@@ -0,0 +1,43 @@
+{
+  "name": "@wildo-ai/systems-of-record",
+  "version": "1.1.6",
+  "license": "SEE LICENSE IN LICENSE",
+  "description": "Wildo system-of-record vendor facets (Odoo, SAP S/4HANA, Microsoft Dataverse, Business Central, NetSuite, Salesforce, generic OData): an opt-in library an application links when it declares systemsOfRecord",
+  "author": "Wildo AI",
+  "type": "module",
+  "sideEffects": false,
+  "exports": {
+    "./systems-of-record": {
+      "types": "./dist/esm/systems-of-record.exports.d.ts",
+      "import": "./dist/esm/systems-of-record.exports.js",
+      "default": "./dist/esm/systems-of-record.exports.js"
+    }
+  },
+  "files": [
+    "dist/"
+  ],
+  "scripts": {
+    "build": "tsc -p tsconfig.build.json && node ../../scripts/run-tsc-alias-safe.mjs --project tsconfig.build.json --dist dist/esm",
+    "dev": "node ../../scripts/run-tsc-watch-single-writer.mjs --dist dist/esm --exec tsc-watch -- -p tsconfig.build.json --preserveWatchOutput --onSuccess \"node ../../scripts/run-tsc-alias-safe.mjs --project tsconfig.build.json --dist dist/esm\"",
+    "rebuild": "pnpm clean && pnpm build",
+    "clean": "rimraf dist",
+    "watch": "node ../../scripts/run-tsc-watch-single-writer.mjs --dist dist/esm --exec tsc-watch -- -p tsconfig.build.json --preserveWatchOutput --onSuccess \"node ../../scripts/run-tsc-alias-safe.mjs --project tsconfig.build.json --dist dist/esm\"",
+    "typecheck": "tsc --noEmit",
+    "test": "vitest run",
+    "test:watch": "vitest"
+  },
+  "dependencies": {
+    "@wildo-ai/saas-models": "1.1.6"
+  },
+  "devDependencies": {
+    "rimraf": "^6.0.1",
+    "tsc-watch": "7.2.1",
+    "typescript": "5.9.3",
+    "vitest": "^1.6.1"
+  },
+  "repository": {
+    "type": "git",
+    "url": "git+https://github.com/wildo-ai/wildo-ai.git",
+    "directory": "engine/systems-of-record"
+  }
+}