npm - @wildo-ai/external-connectors-models - Versions diffs - 1.1.6 → 1.1.7 - Mend

@wildo-ai/external-connectors-models 1.1.6 → 1.1.7

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 (56) hide show

package/dist/esm/protocols/sms.standard-interface.schemas.js.map CHANGED Viewed

	@@ -1 +1 @@
1	- {"version":3,"file":"sms.standard-interface.schemas.js","sourceRoot":"","sources":["~~../../../../~~src/protocols/sms.standard-interface.schemas.ts"],"names":[],"mappings":"AAAA,OAAO,EAAE,CAAC,EAAE,MAAM,KAAK,CAAC;AAExB,kEAAkE;AAClE,yBAAyB;AACzB,WAAW;AACX,qEAAqE;AACrE,sEAAsE;AACtE,+BAA+B;AAC/B,EAAE;AACF,qBAAqB;AACrB,qDAAqD;AACrD,6EAA6E;AAC7E,yEAAyE;AACzE,kEAAkE;AAElE,kEAAkE;AAClE,gCAAgC;AAChC,kEAAkE;AAElE;;;;;;;;;;;;;;;;;;;;;;;GAuBG;AACH,MAAM,CAAN,IAAY,0BAgBX;AAhBD,WAAY,0BAA0B;IACpC;;;;;;;;;;;;;OAaG;IACH,6EAA+C,CAAA;AACjD,CAAC,EAhBW,0BAA0B,KAA1B,0BAA0B,QAgBrC;AAED,kEAAkE;AAClE,4BAA4B;AAC5B,kEAAkE;AAElE,MAAM,CAAC,MAAM,6BAA6B,GAAG,CAAC,CAAC,MAAM,CAAC;IACpD,6CAA6C;IAC7C,EAAE,EAAE,CAAC,CAAC,MAAM,EAAE,CAAC,KAAK,CAAC,oBAAoB,EAAE,EAAE,KAAK,EAAE,8CAA8C,EAAE,CAAC;IAErG,qFAAqF;IACrF,IAAI,EAAE,CAAC,CAAC,MAAM,EAAE,CAAC,QAAQ,EAAE;IAE3B,uBAAuB;IACvB,IAAI,EAAE,CAAC,CAAC,MAAM,EAAE,CAAC,GAAG,CAAC,CAAC,CAAC,CAAC,GAAG,CAAC,IAAI,CAAC;IAEjC,wCAAwC;IACxC,QAAQ,EAAE,CAAC,CAAC,MAAM,CAAC,CAAC,CAAC,MAAM,EAAE,EAAE,CAAC,CAAC,MAAM,EAAE,CAAC,CAAC,QAAQ,EAAE;CACtD,CAAC,CAAC;AAGH,kEAAkE;AAClE,6BAA6B;AAC7B,kEAAkE;AAElE;;;;;;;;;;;;;GAaG;AACH,MAAM,CAAN,IAAY,iBASX;AATD,WAAY,iBAAiB;IAC3B,6DAA6D;IAC7D,sCAAiB,CAAA;IACjB,uDAAuD;IACvD,kCAAa,CAAA;IACb,8CAA8C;IAC9C,4CAAuB,CAAA;IACvB,8FAA8F;IAC9F,sCAAiB,CAAA;AACnB,CAAC,EATW,iBAAiB,KAAjB,iBAAiB,QAS5B;AAED,MAAM,CAAC,MAAM,8BAA8B,GAAG,CAAC,CAAC,MAAM,CAAC;IACrD,OAAO,EAAE,CAAC,CAAC,OAAO,EAAE;IACpB,mCAAmC;IACnC,SAAS,EAAE,CAAC,CAAC,MAAM,EAAE;IACrB,+CAA+C;IAC/C,MAAM,EAAE,CAAC,CAAC,IAAI,CAAC,iBAAiB,CAAC,CAAC,QAAQ,EAAE;CAC7C,CAAC,CAAC;AAGH,kEAAkE;AAClE,qBAAqB;AACrB,kEAAkE;AAElE,MAAM,CAAC,MAAM,uBAAuB,GAAG,CAAC,CAAC,MAAM,CAAC;IAC9C,IAAI,EAAE,CAAC,CAAC,IAAI,CAAC;QACX,kBAAkB;QAClB,gBAAgB;QAChB,sBAAsB;QACtB,qBAAqB;QACrB,uBAAuB;QACvB,gBAAgB;QAChB,eAAe;KAChB,CAAC;IACF,OAAO,EAAE,CAAC,CAAC,MAAM,EAAE;IACnB,QAAQ,EAAE,CAAC,CAAC,MAAM,EAAE,CAAC,QAAQ,EAAE;IAC/B,OAAO,EAAE,CAAC,CAAC,OAAO,EAAE,CAAC,QAAQ,EAAE;CAChC,CAAC,CAAC","sourcesContent":["import { z } from \"zod\";\n\n// ===============================================================\n// Standard SMS Interface\n// --------\n// This is the canonical interface that Wildo uses internally to send\n// SMS messages. The ETL layer transforms these standard requests into\n// provider-specific API calls.\n//\n// Design Principles:\n// 1. Provider-agnostic - works with any SMS provider\n// 2. Minimal surface area - focused on transactional SMS (OTP, verification)\n// 3. Extensible - new fields can be added without breaking existing code\n// ===============================================================\n\n// ===============================================================\n// SMS Provider Credential Shape\n// ===============================================================\n\n/*\n How a `kind: SMS` provider's credential bundle is SHAPED, and therefore how the engine parses\n * the resolved secret and authenticates the send request.\n \n The engine owns this — not the provider — because parsing a bundle means touching the secret,\n * and a provider module's request builder is a pure function that must never see one. So the\n * contract DECLARES which shape it uses and the engine implements it, exactly as the email arm\n * declares `apiKey.scheme` and lets the engine compose the header.\n \n ## Why a single member, and why that is the point\n \n One shape has a declarer today. A member is added here only together with its parse-and-\n * authenticate branch in the SMS transport, and that branch is an exhaustive `switch` with a\n * `never` check — so a member added without an implementation fails COMPILATION rather than\n * shipping a provider the engine cannot authenticate. Equally, a second SMS provider whose\n * credential is shaped differently cannot name a member that does not exist: it is refused at\n * declaration time, which is the strongest available form of \"never silently handed Twilio's\".\n \n An `'api-key'` member stood here until 2026-09-09 and was pure declaration: no production\n * provider named it, no consumer read it, and no code implemented it — its only use anywhere was\n * one test fixture about an unrelated projection. It was removed rather than implemented, because\n * inventing a header shape for a provider that does not exist is inventing a contract nobody can\n * check.\n /\nexport enum SmsProviderCredentialShape {\n /\n A two-part bundle: a non-secret account IDENTIFIER and the secret that authenticates it.\n * The engine authenticates with HTTP Basic — `base64(accountId:secret)` — and makes the\n * account identifier available for substitution into the contract's `sendEndpointPath`.\n \n Basic credentials are carried in the `Authorization` header by definition, so the header name\n * is not a per-provider choice and is deliberately not declared.\n * spec-cite: RFC 7617 §2 (The 'Basic' HTTP Authentication Scheme) — the credentials are the\n * base64 of `user-id \":\" password`, transmitted in the `Authorization` header.\n \n Twilio's `AccountSid` + `AuthToken` is this shape. The name is deliberately NOT Twilio's:\n * the value was `'account-sid-auth-token'` until 2026-09-09, which put one vendor's vocabulary\n * on a contract every SMS provider has to speak.\n /\n ACCOUNT_ID_AND_SECRET = \"account-id-and-secret\",\n}\n\n// ===============================================================\n// Standard SMS Send Request\n// ===============================================================\n\nexport const StandardSMS_SendRequestSchema = z.object({\n /* Recipient phone number in E.164 format /\n to: z.string().regex(/^\\+?[1-9]\\d{1,14}$/, { error: \"Invalid phone number (E.164 format required)\" }),\n\n /* Sender phone number or short code (optional, uses provider default if not set) /\n from: z.string().optional(),\n\n /* SMS message body /\n body: z.string().min(1).max(1600),\n\n /* Metadata for correlation/tracking /\n metadata: z.record(z.string(), z.string()).optional(),\n});\nexport type StandardSMS_SendRequest = z.infer<typeof StandardSMS_SendRequestSchema>;\n\n// ===============================================================\n// Standard SMS Send Response\n// ===============================================================\n\n/\n The delivery states this framework recognises, and the vocabulary a provider's\n * `parseSendResponse` projects its vendor's own states onto.\n \n Named rather than left inline because a vendor's vocabulary is LARGER than this one and the\n * mapping between them is the interesting part. Twilio alone reports `accepted`, `scheduled`,\n * `sending`, `undelivered` and `canceled`, none of which is a member here — so the per-member\n * question \"which vendor states land on this one, and why\" needs somewhere to be answered, and an\n * inline `z.enum` has nowhere to put it.\n \n The four members are unchanged; this only gives them a home. `.optional()` on the field is what\n * says a provider may report NO state, which is the honest answer for a vendor state this\n * vocabulary does not cover — better than forcing a wrong one.\n /\nexport enum SmsDeliveryStatus {\n /* Accepted by the provider, not yet handed to a carrier. /\n QUEUED = \"queued\",\n /* Handed to a carrier; delivery not yet confirmed. /\n SENT = \"sent\",\n /* The carrier confirmed handset delivery. /\n DELIVERED = \"delivered\",\n /* Terminal failure, whether the provider rejected it or the carrier could not deliver it. /\n FAILED = \"failed\",\n}\n\nexport const StandardSMS_SendResponseSchema = z.object({\n success: z.boolean(),\n /* Provider-assigned message ID /\n messageId: z.string(),\n /* Delivery status if available immediately */\n status: z.enum(SmsDeliveryStatus).optional(),\n});\nexport type StandardSMS_SendResponse = z.infer<typeof StandardSMS_SendResponseSchema>;\n\n// ===============================================================\n// Standard SMS Error\n// ===============================================================\n\nexport const StandardSMS_ErrorSchema = z.object({\n code: z.enum([\n \"VALIDATION_ERROR\",\n \"PROVIDER_ERROR\",\n \"INVALID_PHONE_NUMBER\",\n \"RATE_LIMIT_EXCEEDED\",\n \"AUTHENTICATION_FAILED\",\n \"QUOTA_EXCEEDED\",\n \"UNKNOWN_ERROR\",\n ]),\n message: z.string(),\n provider: z.string().optional(),\n details: z.unknown().optional(),\n});\nexport type StandardSMS_Error = z.infer<typeof StandardSMS_ErrorSchema>;\n"]}
1	+ {"version":3,"file":"sms.standard-interface.schemas.js","sourceRoot":"","sources":["../../../src/protocols/sms.standard-interface.schemas.ts"],"names":[],"mappings":"AAAA,OAAO,EAAE,CAAC,EAAE,MAAM,KAAK,CAAC;AAExB,kEAAkE;AAClE,yBAAyB;AACzB,WAAW;AACX,qEAAqE;AACrE,sEAAsE;AACtE,+BAA+B;AAC/B,EAAE;AACF,qBAAqB;AACrB,qDAAqD;AACrD,6EAA6E;AAC7E,yEAAyE;AACzE,kEAAkE;AAElE,kEAAkE;AAClE,gCAAgC;AAChC,kEAAkE;AAElE;;;;;;;;;;;;;;;;;;;;;;;GAuBG;AACH,MAAM,CAAN,IAAY,0BAgBX;AAhBD,WAAY,0BAA0B;IACpC;;;;;;;;;;;;;OAaG;IACH,6EAA+C,CAAA;AACjD,CAAC,EAhBW,0BAA0B,KAA1B,0BAA0B,QAgBrC;AAED,kEAAkE;AAClE,4BAA4B;AAC5B,kEAAkE;AAElE,MAAM,CAAC,MAAM,6BAA6B,GAAG,CAAC,CAAC,MAAM,CAAC;IACpD,6CAA6C;IAC7C,EAAE,EAAE,CAAC,CAAC,MAAM,EAAE,CAAC,KAAK,CAAC,oBAAoB,EAAE,EAAE,KAAK,EAAE,8CAA8C,EAAE,CAAC;IAErG,qFAAqF;IACrF,IAAI,EAAE,CAAC,CAAC,MAAM,EAAE,CAAC,QAAQ,EAAE;IAE3B,uBAAuB;IACvB,IAAI,EAAE,CAAC,CAAC,MAAM,EAAE,CAAC,GAAG,CAAC,CAAC,CAAC,CAAC,GAAG,CAAC,IAAI,CAAC;IAEjC,wCAAwC;IACxC,QAAQ,EAAE,CAAC,CAAC,MAAM,CAAC,CAAC,CAAC,MAAM,EAAE,EAAE,CAAC,CAAC,MAAM,EAAE,CAAC,CAAC,QAAQ,EAAE;CACtD,CAAC,CAAC;AAGH,kEAAkE;AAClE,6BAA6B;AAC7B,kEAAkE;AAElE;;;;;;;;;;;;;GAaG;AACH,MAAM,CAAN,IAAY,iBASX;AATD,WAAY,iBAAiB;IAC3B,6DAA6D;IAC7D,sCAAiB,CAAA;IACjB,uDAAuD;IACvD,kCAAa,CAAA;IACb,8CAA8C;IAC9C,4CAAuB,CAAA;IACvB,8FAA8F;IAC9F,sCAAiB,CAAA;AACnB,CAAC,EATW,iBAAiB,KAAjB,iBAAiB,QAS5B;AAED,MAAM,CAAC,MAAM,8BAA8B,GAAG,CAAC,CAAC,MAAM,CAAC;IACrD,OAAO,EAAE,CAAC,CAAC,OAAO,EAAE;IACpB,mCAAmC;IACnC,SAAS,EAAE,CAAC,CAAC,MAAM,EAAE;IACrB,+CAA+C;IAC/C,MAAM,EAAE,CAAC,CAAC,IAAI,CAAC,iBAAiB,CAAC,CAAC,QAAQ,EAAE;CAC7C,CAAC,CAAC;AAGH,kEAAkE;AAClE,qBAAqB;AACrB,kEAAkE;AAElE,MAAM,CAAC,MAAM,uBAAuB,GAAG,CAAC,CAAC,MAAM,CAAC;IAC9C,IAAI,EAAE,CAAC,CAAC,IAAI,CAAC;QACX,kBAAkB;QAClB,gBAAgB;QAChB,sBAAsB;QACtB,qBAAqB;QACrB,uBAAuB;QACvB,gBAAgB;QAChB,eAAe;KAChB,CAAC;IACF,OAAO,EAAE,CAAC,CAAC,MAAM,EAAE;IACnB,QAAQ,EAAE,CAAC,CAAC,MAAM,EAAE,CAAC,QAAQ,EAAE;IAC/B,OAAO,EAAE,CAAC,CAAC,OAAO,EAAE,CAAC,QAAQ,EAAE;CAChC,CAAC,CAAC","sourcesContent":["import { z } from \"zod\";\n\n// ===============================================================\n// Standard SMS Interface\n// --------\n// This is the canonical interface that Wildo uses internally to send\n// SMS messages. The ETL layer transforms these standard requests into\n// provider-specific API calls.\n//\n// Design Principles:\n// 1. Provider-agnostic - works with any SMS provider\n// 2. Minimal surface area - focused on transactional SMS (OTP, verification)\n// 3. Extensible - new fields can be added without breaking existing code\n// ===============================================================\n\n// ===============================================================\n// SMS Provider Credential Shape\n// ===============================================================\n\n/*\n How a `kind: SMS` provider's credential bundle is SHAPED, and therefore how the engine parses\n * the resolved secret and authenticates the send request.\n \n The engine owns this — not the provider — because parsing a bundle means touching the secret,\n * and a provider module's request builder is a pure function that must never see one. So the\n * contract DECLARES which shape it uses and the engine implements it, exactly as the email arm\n * declares `apiKey.scheme` and lets the engine compose the header.\n \n ## Why a single member, and why that is the point\n \n One shape has a declarer today. A member is added here only together with its parse-and-\n * authenticate branch in the SMS transport, and that branch is an exhaustive `switch` with a\n * `never` check — so a member added without an implementation fails COMPILATION rather than\n * shipping a provider the engine cannot authenticate. Equally, a second SMS provider whose\n * credential is shaped differently cannot name a member that does not exist: it is refused at\n * declaration time, which is the strongest available form of \"never silently handed Twilio's\".\n \n An `'api-key'` member stood here until 2026-09-09 and was pure declaration: no production\n * provider named it, no consumer read it, and no code implemented it — its only use anywhere was\n * one test fixture about an unrelated projection. It was removed rather than implemented, because\n * inventing a header shape for a provider that does not exist is inventing a contract nobody can\n * check.\n /\nexport enum SmsProviderCredentialShape {\n /\n A two-part bundle: a non-secret account IDENTIFIER and the secret that authenticates it.\n * The engine authenticates with HTTP Basic — `base64(accountId:secret)` — and makes the\n * account identifier available for substitution into the contract's `sendEndpointPath`.\n \n Basic credentials are carried in the `Authorization` header by definition, so the header name\n * is not a per-provider choice and is deliberately not declared.\n * spec-cite: RFC 7617 §2 (The 'Basic' HTTP Authentication Scheme) — the credentials are the\n * base64 of `user-id \":\" password`, transmitted in the `Authorization` header.\n \n Twilio's `AccountSid` + `AuthToken` is this shape. The name is deliberately NOT Twilio's:\n * the value was `'account-sid-auth-token'` until 2026-09-09, which put one vendor's vocabulary\n * on a contract every SMS provider has to speak.\n /\n ACCOUNT_ID_AND_SECRET = \"account-id-and-secret\",\n}\n\n// ===============================================================\n// Standard SMS Send Request\n// ===============================================================\n\nexport const StandardSMS_SendRequestSchema = z.object({\n /* Recipient phone number in E.164 format /\n to: z.string().regex(/^\\+?[1-9]\\d{1,14}$/, { error: \"Invalid phone number (E.164 format required)\" }),\n\n /* Sender phone number or short code (optional, uses provider default if not set) /\n from: z.string().optional(),\n\n /* SMS message body /\n body: z.string().min(1).max(1600),\n\n /* Metadata for correlation/tracking /\n metadata: z.record(z.string(), z.string()).optional(),\n});\nexport type StandardSMS_SendRequest = z.infer<typeof StandardSMS_SendRequestSchema>;\n\n// ===============================================================\n// Standard SMS Send Response\n// ===============================================================\n\n/\n The delivery states this framework recognises, and the vocabulary a provider's\n * `parseSendResponse` projects its vendor's own states onto.\n \n Named rather than left inline because a vendor's vocabulary is LARGER than this one and the\n * mapping between them is the interesting part. Twilio alone reports `accepted`, `scheduled`,\n * `sending`, `undelivered` and `canceled`, none of which is a member here — so the per-member\n * question \"which vendor states land on this one, and why\" needs somewhere to be answered, and an\n * inline `z.enum` has nowhere to put it.\n \n The four members are unchanged; this only gives them a home. `.optional()` on the field is what\n * says a provider may report NO state, which is the honest answer for a vendor state this\n * vocabulary does not cover — better than forcing a wrong one.\n /\nexport enum SmsDeliveryStatus {\n /* Accepted by the provider, not yet handed to a carrier. /\n QUEUED = \"queued\",\n /* Handed to a carrier; delivery not yet confirmed. /\n SENT = \"sent\",\n /* The carrier confirmed handset delivery. /\n DELIVERED = \"delivered\",\n /* Terminal failure, whether the provider rejected it or the carrier could not deliver it. /\n FAILED = \"failed\",\n}\n\nexport const StandardSMS_SendResponseSchema = z.object({\n success: z.boolean(),\n /* Provider-assigned message ID /\n messageId: z.string(),\n /* Delivery status if available immediately */\n status: z.enum(SmsDeliveryStatus).optional(),\n});\nexport type StandardSMS_SendResponse = z.infer<typeof StandardSMS_SendResponseSchema>;\n\n// ===============================================================\n// Standard SMS Error\n// ===============================================================\n\nexport const StandardSMS_ErrorSchema = z.object({\n code: z.enum([\n \"VALIDATION_ERROR\",\n \"PROVIDER_ERROR\",\n \"INVALID_PHONE_NUMBER\",\n \"RATE_LIMIT_EXCEEDED\",\n \"AUTHENTICATION_FAILED\",\n \"QUOTA_EXCEEDED\",\n \"UNKNOWN_ERROR\",\n ]),\n message: z.string(),\n provider: z.string().optional(),\n details: z.unknown().optional(),\n});\nexport type StandardSMS_Error = z.infer<typeof StandardSMS_ErrorSchema>;\n"]}