@cxpinsight/survey-spec 0.3.0 → 0.5.0
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.
- package/dist/evaluateTree.d.ts +50 -0
- package/dist/evaluateTree.d.ts.map +1 -0
- package/dist/evaluateTree.js +166 -0
- package/dist/index.d.ts +7 -2
- package/dist/index.d.ts.map +1 -1
- package/dist/index.js +28 -1
- package/dist/messages.d.ts +38 -0
- package/dist/messages.d.ts.map +1 -0
- package/dist/messages.js +68 -0
- package/dist/resolveVariable.d.ts.map +1 -1
- package/dist/resolveVariable.js +13 -0
- package/dist/validate.d.ts +314 -39
- package/dist/validate.d.ts.map +1 -1
- package/dist/validate.js +577 -24
- package/dist/voice.d.ts.map +1 -1
- package/dist/voice.js +3 -0
- package/package.json +1 -1
package/dist/validate.d.ts
CHANGED
|
@@ -1,41 +1,4 @@
|
|
|
1
|
-
|
|
2
|
-
* Answer validation — whether a respondent may submit.
|
|
3
|
-
*
|
|
4
|
-
* A divergence here means the same answer is accepted on one channel and
|
|
5
|
-
* rejected on another. The respondent hits a wall that does not exist for
|
|
6
|
-
* someone who arrived by a different route, and an analyst comparing the two
|
|
7
|
-
* sets of responses is comparing two instruments.
|
|
8
|
-
*
|
|
9
|
-
* There were three implementations and all three disagreed:
|
|
10
|
-
*
|
|
11
|
-
* • The WEB SDK had none. `survey.js` checked emptiness inline at the Next
|
|
12
|
-
* button and nothing else, so it accepted 8 of 32 answers the others
|
|
13
|
-
* rejected — including whitespace against a required question, `nope` as an
|
|
14
|
-
* email address, and any string against `minLength`.
|
|
15
|
-
*
|
|
16
|
-
* • REACT and MOBILE agreed on 26 fixtures and still differed, because every
|
|
17
|
-
* one of those fixtures used `type: 'text'` with an `inputType`. React's
|
|
18
|
-
* dispatcher has no case for `email`, `number`, `csat` or `ces` as question
|
|
19
|
-
* TYPES, so a question of `type: 'email'` was format-checked on the phone
|
|
20
|
-
* and waved through on a link.
|
|
21
|
-
*
|
|
22
|
-
* This module is the union, and each half was chosen for a reason:
|
|
23
|
-
*
|
|
24
|
-
* • `isEmpty` is React's, because it is type-aware. The web renderer's values
|
|
25
|
-
* are compound — `{ choice }`, `{ choices }`, `{ text, attachments }` — and
|
|
26
|
-
* mobile's primitives pass through the same code unharmed. Mobile's
|
|
27
|
-
* primitive-only version would have called `{ choice: undefined }` non-empty
|
|
28
|
-
* and let a blank required radio through.
|
|
29
|
-
*
|
|
30
|
-
* • The type dispatcher is mobile's, because it is the superset, and the
|
|
31
|
-
* effective format is derived from `inputType || type` so `type: 'email'`
|
|
32
|
-
* validates as an email whether or not the author also set an inputType.
|
|
33
|
-
*
|
|
34
|
-
* Order is spec §8 and it matters: required, then type-specific format, then
|
|
35
|
-
* the author's `rules[]`. An empty answer should read "this is required", not
|
|
36
|
-
* "that is not a valid email" — which sounds like the shape is wrong rather
|
|
37
|
-
* than the field being blank.
|
|
38
|
-
*/
|
|
1
|
+
import { type ValidationMessage } from './messages';
|
|
39
2
|
export interface ValidatableQuestion {
|
|
40
3
|
type?: string;
|
|
41
4
|
inputType?: string;
|
|
@@ -48,7 +11,319 @@ export interface ValidatableQuestion {
|
|
|
48
11
|
minCount?: number;
|
|
49
12
|
maxCount?: number;
|
|
50
13
|
rules?: unknown;
|
|
14
|
+
/** implied: the actions offered. The choices ARE the buttons. */
|
|
15
|
+
choices?: unknown;
|
|
16
|
+
options?: unknown;
|
|
51
17
|
}
|
|
52
|
-
/**
|
|
18
|
+
/**
|
|
19
|
+
* Null when the answer is valid; otherwise the ENGLISH message to show.
|
|
20
|
+
*
|
|
21
|
+
* The signature is unchanged on purpose — three renderers call this and expect
|
|
22
|
+
* a string. The wording now comes from one table (messages.ts) rather than
|
|
23
|
+
* being built inside the rules, so a renderer that wants another language calls
|
|
24
|
+
* `validateAnswerCode` and words the code itself.
|
|
25
|
+
*/
|
|
53
26
|
export declare function validateAnswer(question: ValidatableQuestion, value: unknown): string | null;
|
|
27
|
+
/** The same rules, as a code and its parameters. This is what a port implements. */
|
|
28
|
+
export declare function validateAnswerCode(question: ValidatableQuestion, value: unknown): ValidationMessage | null;
|
|
29
|
+
/** The values an implied question offers, in order. Its buttons, effectively. */
|
|
30
|
+
export declare function impliedChoices(question: ValidatableQuestion): string[];
|
|
31
|
+
/**
|
|
32
|
+
* The label a renderer should put on each action button, paired with the value
|
|
33
|
+
* it records. One place, so "Activate discount" reads the same on a website,
|
|
34
|
+
* a link and a phone.
|
|
35
|
+
*/
|
|
36
|
+
export declare function impliedActions(question: ValidatableQuestion): Array<{
|
|
37
|
+
value: string;
|
|
38
|
+
label: string;
|
|
39
|
+
href?: string;
|
|
40
|
+
defer?: boolean;
|
|
41
|
+
}>;
|
|
42
|
+
/**
|
|
43
|
+
* Is this choice a "Remind me later" — a deferral rather than an answer?
|
|
44
|
+
*
|
|
45
|
+
* A deferring choice CLOSES the surface AND RECORDS A SKIP, and deliberately
|
|
46
|
+
* does not submit. That distinction is the whole feature: a skip feeds
|
|
47
|
+
* cooldownOnSkip and maxSkips, so the interaction comes back after the wait and
|
|
48
|
+
* gives up after the last try. A submission feeds maxSubmissions, which means
|
|
49
|
+
* "they decided" — and a person who asked to be reminded has decided nothing.
|
|
50
|
+
*
|
|
51
|
+
* Without this, "Remind me later" could only be built as an ordinary choice,
|
|
52
|
+
* which recorded an answer and retired the interaction for good: the one button
|
|
53
|
+
* whose entire purpose is to bring it back was the one that guaranteed it never
|
|
54
|
+
* would.
|
|
55
|
+
*
|
|
56
|
+
* NEVER ON A COMPLIANCE SURFACE, and not as a matter of taste. must-show
|
|
57
|
+
* bypasses the frequency gate entirely while unsatisfied, so a deferral there
|
|
58
|
+
* would be inert — the takeover would reappear immediately and the button would
|
|
59
|
+
* be a visible lie. If someone may genuinely postpone, the interaction is not
|
|
60
|
+
* must-show, and that is the setting to change.
|
|
61
|
+
*/
|
|
62
|
+
export declare function isDeferChoice(choice: unknown, interactionType?: string | null): boolean;
|
|
63
|
+
/**
|
|
64
|
+
* The navigable target of a choice's `action`, or undefined.
|
|
65
|
+
*
|
|
66
|
+
* Only `type: 'url'` navigates today, and only to a scheme that cannot execute
|
|
67
|
+
* script in the host page. `javascript:` and `data:` are the two that can, so
|
|
68
|
+
* an author-supplied (or API-supplied) action is not a place to be permissive:
|
|
69
|
+
* a survey definition travels from the server into a customer's own site, and a
|
|
70
|
+
* URL that runs code there is an XSS vector wearing a button.
|
|
71
|
+
*
|
|
72
|
+
* Relative paths and app deep-link schemes are allowed — a mobile nudge that
|
|
73
|
+
* opens `myapp://cart` is the point of the feature.
|
|
74
|
+
*/
|
|
75
|
+
export declare function safeActionHref(action: unknown): string | undefined;
|
|
76
|
+
/**
|
|
77
|
+
* The `src` for an image the author placed in a survey, or '' to draw nothing.
|
|
78
|
+
*
|
|
79
|
+
* SEPARATE FROM safeActionHref ON PURPOSE. That one guards a NAVIGATION target,
|
|
80
|
+
* where `data:` is an XSS vector wearing a button — a URL the host page is told
|
|
81
|
+
* to follow. This guards an IMAGE SOURCE, which the host page only ever
|
|
82
|
+
* decodes as pixels, and `data:image/...;base64,` is exactly how the builder
|
|
83
|
+
* stores an uploaded picture: there is no file host in the product, so an
|
|
84
|
+
* upload becomes a data URI or it becomes nothing.
|
|
85
|
+
*
|
|
86
|
+
* Collapsing the two was a real bug, not a hypothetical one. The web SDK ran
|
|
87
|
+
* every image through its link guard, which allows only http/https/mailto/tel,
|
|
88
|
+
* so every uploaded offer image was rewritten to `src=""` and vanished —
|
|
89
|
+
* on the web and mobile preview frames, which both run the SDK, while the link
|
|
90
|
+
* surface (React, no guard) showed it. An author saw their picture appear on
|
|
91
|
+
* one surface out of three and had no way to tell why.
|
|
92
|
+
*
|
|
93
|
+
* `<img>` is a non-scripting context: an SVG loaded through it cannot run its
|
|
94
|
+
* own script, so `data:image/*` is safe here in a way it is not on an href.
|
|
95
|
+
* Everything else with a scheme is still refused — `data:text/html` most of
|
|
96
|
+
* all, which is the one that would actually execute.
|
|
97
|
+
*/
|
|
98
|
+
export declare function safeImageSrc(url: unknown): string;
|
|
99
|
+
/**
|
|
100
|
+
* The action buttons for a STEP, or [] for an ordinary step.
|
|
101
|
+
*
|
|
102
|
+
* A Notify, Offer or Comply interaction's buttons are its ANSWER — "Activate
|
|
103
|
+
* discount" and "No thanks" are the two things the respondent can say, not
|
|
104
|
+
* decoration beside a Next button. So a step that ends in an implied question
|
|
105
|
+
* has NO Next and NO Submit: pressing an action IS the submission.
|
|
106
|
+
*
|
|
107
|
+
* The rule lives here because all three renderers have to agree on it. When
|
|
108
|
+
* they didn't, the web SDK replaced Next with the actions while the React and
|
|
109
|
+
* React Native renderers drew the actions AND kept Submit — the respondent saw
|
|
110
|
+
* "Resume" and "Submit" stacked, and pressing Resume did nothing but tick a
|
|
111
|
+
* radio nobody could see.
|
|
112
|
+
*
|
|
113
|
+
* The LAST question decides. A step is allowed to carry content above the
|
|
114
|
+
* actions (a paragraph of terms, an image); what closes it is what turns it
|
|
115
|
+
* into a decision.
|
|
116
|
+
*
|
|
117
|
+
* Never returns an empty list for an implied step: an implied question with no
|
|
118
|
+
* choices would be a dead end — no buttons and no way out — so one neutral
|
|
119
|
+
* action beats a surface the respondent cannot leave.
|
|
120
|
+
*/
|
|
121
|
+
export declare function impliedStepActions(questions: ValidatableQuestion[] | null | undefined): Array<{
|
|
122
|
+
value: string;
|
|
123
|
+
label: string;
|
|
124
|
+
}>;
|
|
125
|
+
/**
|
|
126
|
+
* Should this step's actions render with EQUAL PROMINENCE?
|
|
127
|
+
*
|
|
128
|
+
* A consent choice is not a call to action with an escape hatch. When accept is
|
|
129
|
+
* a filled accent button and decline is a quiet outline, the design is doing
|
|
130
|
+
* persuasion work on a decision that must be freely given — the pattern
|
|
131
|
+
* regulators name when they talk about consent dark patterns, and the reason
|
|
132
|
+
* `equalProminence` exists on the question.
|
|
133
|
+
*
|
|
134
|
+
* It was being SET by the compliance templates and read by nothing, so both
|
|
135
|
+
* shipped with a filled "I agree" beside a ghosted "Decline".
|
|
136
|
+
*
|
|
137
|
+
* Same "last question decides" rule as impliedStepActions, so the two can never
|
|
138
|
+
* disagree about which question they are talking about.
|
|
139
|
+
*/
|
|
140
|
+
export declare function impliedEqualProminence(questions: ValidatableQuestion[] | null | undefined): boolean;
|
|
141
|
+
/**
|
|
142
|
+
* May this surface be dismissed by SWIPING it away?
|
|
143
|
+
*
|
|
144
|
+
* A push notification on a phone has no ✕. It slides down, and it leaves when
|
|
145
|
+
* you flick it. Removing the close button without providing the gesture would
|
|
146
|
+
* just make it untouchable, so the two decisions are one decision and it lives
|
|
147
|
+
* here rather than three times over.
|
|
148
|
+
*
|
|
149
|
+
* THE FULLSCREEN EXCLUSION IS THE WHOLE POINT. A compliance takeover ALSO sets
|
|
150
|
+
* showClose:false — for the opposite reason: it must not be escapable. Deriving
|
|
151
|
+
* "swipeable" from "has no close button" alone would hand every terms prompt and
|
|
152
|
+
* age check a flick-to-skip gesture, which is precisely the thing that makes it
|
|
153
|
+
* a blocking surface. So a swipe needs a POPUP, and a `mustShow` interaction is
|
|
154
|
+
* never swipeable whatever its mode.
|
|
155
|
+
*
|
|
156
|
+
* @param display The resolved display slice for THIS surface (already picked
|
|
157
|
+
* per platform — a web slice is not a mobile one).
|
|
158
|
+
* @param delivery The survey's delivery policy, for the mustShow veto.
|
|
159
|
+
*/
|
|
160
|
+
export declare function canSwipeToDismiss(display: {
|
|
161
|
+
mode?: unknown;
|
|
162
|
+
showClose?: unknown;
|
|
163
|
+
} | null | undefined, delivery?: {
|
|
164
|
+
mustShow?: unknown;
|
|
165
|
+
} | null): boolean;
|
|
166
|
+
/**
|
|
167
|
+
* How long before this surface dismisses ITSELF, in ms. 0 = never.
|
|
168
|
+
*
|
|
169
|
+
* A push notification leaves on its own; that is most of what separates it from
|
|
170
|
+
* a dialog. `autoDismiss` was named in the interaction profile as a control the
|
|
171
|
+
* notify purpose leads with, and then existed nowhere else — no field, no UI, no
|
|
172
|
+
* timer — so every notification sat there until someone dealt with it.
|
|
173
|
+
*
|
|
174
|
+
* TWO SURFACES MUST NEVER SELF-DISMISS, and both would be silent disasters:
|
|
175
|
+
*
|
|
176
|
+
* - A LINK IS THE PAGE. Auto-dismissing there does not tidy a banner away, it
|
|
177
|
+
* blanks the page the respondent deliberately opened. The caller passes the
|
|
178
|
+
* resolved slice, so a link slice simply never carries the value — but the
|
|
179
|
+
* mode check below makes it structural rather than a matter of nobody
|
|
180
|
+
* having set it.
|
|
181
|
+
* - A BLOCKING SURFACE. Fullscreen compliance and anything `mustShow` exist to
|
|
182
|
+
* be answered; a timer that clears them is an escape hatch with a stopwatch.
|
|
183
|
+
*
|
|
184
|
+
* Clamped to 2s minimum: a notification that vanishes faster than it can be
|
|
185
|
+
* read is worse than one that never appeared, and it is the accessibility
|
|
186
|
+
* complaint that gets filed about auto-dismissing content.
|
|
187
|
+
*/
|
|
188
|
+
export declare function autoDismissMs(display: {
|
|
189
|
+
mode?: unknown;
|
|
190
|
+
autoDismiss?: unknown;
|
|
191
|
+
} | null | undefined, delivery?: {
|
|
192
|
+
mustShow?: unknown;
|
|
193
|
+
} | null): number;
|
|
194
|
+
/**
|
|
195
|
+
* The countdown to show on an interaction, or null.
|
|
196
|
+
*
|
|
197
|
+
* THE TIMER IS THE DEADLINE — it is not a separate number an author types.
|
|
198
|
+
* That identity is the whole design: the survey's `endDate` is what the
|
|
199
|
+
* eligibility gate already enforces, so a countdown derived from it cannot
|
|
200
|
+
* outlive the thing it counts down to. An independently-authored timer can, and
|
|
201
|
+
* an offer whose clock hits zero while the discount still works (or keeps
|
|
202
|
+
* ticking after it stops) is the expired-deadline dark pattern the validity
|
|
203
|
+
* gate exists to prevent.
|
|
204
|
+
*
|
|
205
|
+
* Returns null when there is no deadline, when it has already passed (the gate
|
|
206
|
+
* stops serving then anyway), or when the surface has not asked to show one.
|
|
207
|
+
* Never invents a deadline.
|
|
208
|
+
*/
|
|
209
|
+
export declare function deadlineCountdown(survey: {
|
|
210
|
+
endDate?: unknown;
|
|
211
|
+
} | null | undefined, display?: {
|
|
212
|
+
showDeadline?: unknown;
|
|
213
|
+
} | null, now?: number): {
|
|
214
|
+
ms: number;
|
|
215
|
+
text: string;
|
|
216
|
+
} | null;
|
|
217
|
+
/** "3d 4h" · "4h 12m" · "12m 30s" · "30s" — two units at most, never a wall of zeros. */
|
|
218
|
+
export declare function formatCountdown(ms: number): string;
|
|
219
|
+
export type OutcomeKind = 'thanks' | 'navigate' | 'dismiss' | 'fulfil' | 'unblock' | 'hold';
|
|
220
|
+
export interface OutcomeInput {
|
|
221
|
+
interactionType?: string | null;
|
|
222
|
+
/** The implied choice taken, e.g. 'accepted' | 'declined' | 'resumed'. */
|
|
223
|
+
action?: string | null;
|
|
224
|
+
/** True when the chosen action is the affirmative one (first choice). */
|
|
225
|
+
affirmative?: boolean;
|
|
226
|
+
reward?: {
|
|
227
|
+
type?: unknown;
|
|
228
|
+
value?: unknown;
|
|
229
|
+
whereValid?: unknown;
|
|
230
|
+
} | null;
|
|
231
|
+
compliance?: {
|
|
232
|
+
reviewRequired?: unknown;
|
|
233
|
+
onDecline?: unknown;
|
|
234
|
+
blockedMessage?: unknown;
|
|
235
|
+
} | null;
|
|
236
|
+
}
|
|
237
|
+
/**
|
|
238
|
+
* Decide the ending.
|
|
239
|
+
*
|
|
240
|
+
* The compliance branch is the one with teeth. Accepting is NOT the same as
|
|
241
|
+
* being cleared: when a human has to review an identity document, letting the
|
|
242
|
+
* customer through on submit tells them they are finished when they are not,
|
|
243
|
+
* and defeats the check. So `reviewRequired` holds the surface up, and a
|
|
244
|
+
* decline holds it too unless the author chose otherwise — a compliance
|
|
245
|
+
* surface you get past by saying no is not a compliance surface.
|
|
246
|
+
*/
|
|
247
|
+
export declare function outcomeFor(input: OutcomeInput): OutcomeKind;
|
|
248
|
+
/**
|
|
249
|
+
* Can voice mode do anything on this step?
|
|
250
|
+
*
|
|
251
|
+
* A notification, an offer and a compliance takeover ask one question whose
|
|
252
|
+
* answer is which button you pressed. A microphone on that surface offers to
|
|
253
|
+
* transcribe nothing — it was showing up on offers because `voiceMode` was
|
|
254
|
+
* merely DEFAULTED off on newer templates, so any interaction created before
|
|
255
|
+
* that, or through the API, still rendered one.
|
|
256
|
+
*
|
|
257
|
+
* Structural, not a default: if the step has no answerable input, voice is off
|
|
258
|
+
* regardless of what the survey or the application says.
|
|
259
|
+
*/
|
|
260
|
+
export declare function voiceUsable(questions: ValidatableQuestion[] | null | undefined): boolean;
|
|
261
|
+
/** The reward, ready to show — or null when there is nothing to hand over. */
|
|
262
|
+
export declare function rewardToShow(survey: {
|
|
263
|
+
reward?: {
|
|
264
|
+
type?: unknown;
|
|
265
|
+
value?: unknown;
|
|
266
|
+
whereValid?: unknown;
|
|
267
|
+
} | null;
|
|
268
|
+
endDate?: unknown;
|
|
269
|
+
} | null | undefined): {
|
|
270
|
+
type: string;
|
|
271
|
+
value: string;
|
|
272
|
+
whereValid: string;
|
|
273
|
+
expiresAt: string | null;
|
|
274
|
+
} | null;
|
|
275
|
+
/**
|
|
276
|
+
* Where clicking the CARD ITSELF should take someone, or null.
|
|
277
|
+
*
|
|
278
|
+
* People tap the message, not the button — so a notification's whole card is
|
|
279
|
+
* the click target. This was derived behaviour ("one action that has a link");
|
|
280
|
+
* it is now something an author sets, with the derived rule as the default so
|
|
281
|
+
* nothing that already worked stops working.
|
|
282
|
+
*
|
|
283
|
+
* THE TWO-ACTION VETO IS ABSOLUTE and not an author's to override. On a card
|
|
284
|
+
* offering accept and decline, a stray click anywhere would have to mean one of
|
|
285
|
+
* them — and on a consent surface that would manufacture agreement from a
|
|
286
|
+
* mis-tap. So a card is only ever clickable when it asks for exactly one thing.
|
|
287
|
+
*/
|
|
288
|
+
export declare function cardClickTarget(display: {
|
|
289
|
+
cardClickable?: unknown;
|
|
290
|
+
cardHref?: unknown;
|
|
291
|
+
} | null | undefined, actions: Array<{
|
|
292
|
+
href?: string;
|
|
293
|
+
}> | null | undefined): string | null;
|
|
294
|
+
/** Hover treatment for a clickable card. Pointer devices only. */
|
|
295
|
+
export declare function cardHoverEffect(display: {
|
|
296
|
+
hoverEffect?: unknown;
|
|
297
|
+
} | null | undefined): 'none' | 'lift' | 'glow' | 'tint';
|
|
298
|
+
export type ActionKind = 'url' | 'event' | 'webhook';
|
|
299
|
+
export interface RawAction {
|
|
300
|
+
type?: unknown;
|
|
301
|
+
value?: unknown;
|
|
302
|
+
/** For 'event': the name the host application listens for. */
|
|
303
|
+
eventName?: unknown;
|
|
304
|
+
/** Template payload — values may contain {{variable}} references. */
|
|
305
|
+
payload?: unknown;
|
|
306
|
+
}
|
|
307
|
+
export interface ResolvedAction {
|
|
308
|
+
kind: ActionKind;
|
|
309
|
+
/** Navigable target for 'url', endpoint for 'webhook'. Null when unusable. */
|
|
310
|
+
href: string | null;
|
|
311
|
+
eventName: string | null;
|
|
312
|
+
/** Payload with every {{reference}} substituted. */
|
|
313
|
+
payload: Record<string, string>;
|
|
314
|
+
}
|
|
315
|
+
/**
|
|
316
|
+
* Resolve an action against a variable context.
|
|
317
|
+
*
|
|
318
|
+
* `interpolate` is supplied by the caller because each renderer already owns
|
|
319
|
+
* one, with its own context — the web SDK's reads the trigger event and device
|
|
320
|
+
* signals, the link renderer's reads URL params and answers. Passing the
|
|
321
|
+
* function keeps one rule here and one context there.
|
|
322
|
+
*
|
|
323
|
+
* INTERPOLATE FIRST, THEN CHECK THE SCHEME. A variable is data from outside —
|
|
324
|
+
* a URL parameter, a trait, an event field — so validating the template and
|
|
325
|
+
* then substituting would let `{{next}}` smuggle in `javascript:`. safeActionHref
|
|
326
|
+
* runs on the FINISHED string.
|
|
327
|
+
*/
|
|
328
|
+
export declare function resolveAction(action: RawAction | null | undefined, interpolate?: (s: string) => string): ResolvedAction | null;
|
|
54
329
|
//# sourceMappingURL=validate.d.ts.map
|
package/dist/validate.d.ts.map
CHANGED
|
@@ -1 +1 @@
|
|
|
1
|
-
{"version":3,"file":"validate.d.ts","sourceRoot":"","sources":["../src/validate.ts"],"names":[],"mappings":"AAAA
|
|
1
|
+
{"version":3,"file":"validate.d.ts","sourceRoot":"","sources":["../src/validate.ts"],"names":[],"mappings":"AAAA,OAAO,EAAe,KAAK,iBAAiB,EAAE,MAAM,YAAY,CAAC;AAkDjE,MAAM,WAAW,mBAAmB;IAClC,IAAI,CAAC,EAAE,MAAM,CAAC;IACd,SAAS,CAAC,EAAE,MAAM,CAAC;IACnB,QAAQ,CAAC,EAAE,OAAO,CAAC;IACnB,UAAU,CAAC,EAAE,OAAO,CAAC;IACrB,SAAS,CAAC,EAAE,MAAM,CAAC;IACnB,SAAS,CAAC,EAAE,MAAM,CAAC;IACnB,QAAQ,CAAC,EAAE,MAAM,CAAC;IAClB,QAAQ,CAAC,EAAE,MAAM,CAAC;IAClB,QAAQ,CAAC,EAAE,MAAM,CAAC;IAClB,QAAQ,CAAC,EAAE,MAAM,CAAC;IAClB,KAAK,CAAC,EAAE,OAAO,CAAC;IAChB,iEAAiE;IACjE,OAAO,CAAC,EAAE,OAAO,CAAC;IAClB,OAAO,CAAC,EAAE,OAAO,CAAC;CACnB;AAED;;;;;;;GAOG;AACH,wBAAgB,cAAc,CAAC,QAAQ,EAAE,mBAAmB,EAAE,KAAK,EAAE,OAAO,GAAG,MAAM,GAAG,IAAI,CAE3F;AAED,oFAAoF;AACpF,wBAAgB,kBAAkB,CAAC,QAAQ,EAAE,mBAAmB,EAAE,KAAK,EAAE,OAAO,GAAG,iBAAiB,GAAG,IAAI,CAgB1G;AA4ND,iFAAiF;AACjF,wBAAgB,cAAc,CAAC,QAAQ,EAAE,mBAAmB,GAAG,MAAM,EAAE,CAetE;AAED;;;;GAIG;AACH,wBAAgB,cAAc,CAC5B,QAAQ,EAAE,mBAAmB,GAC5B,KAAK,CAAC;IAAE,KAAK,EAAE,MAAM,CAAC;IAAC,KAAK,EAAE,MAAM,CAAC;IAAC,IAAI,CAAC,EAAE,MAAM,CAAC;IAAC,KAAK,CAAC,EAAE,OAAO,CAAA;CAAE,CAAC,CA8BzE;AAED;;;;;;;;;;;;;;;;;;;GAmBG;AACH,wBAAgB,aAAa,CAAC,MAAM,EAAE,OAAO,EAAE,eAAe,CAAC,EAAE,MAAM,GAAG,IAAI,GAAG,OAAO,CAIvF;AAED;;;;;;;;;;;GAWG;AACH,wBAAgB,cAAc,CAAC,MAAM,EAAE,OAAO,GAAG,MAAM,GAAG,SAAS,CAalE;AAED;;;;;;;;;;;;;;;;;;;;;GAqBG;AACH,wBAAgB,YAAY,CAAC,GAAG,EAAE,OAAO,GAAG,MAAM,CAajD;AAED;;;;;;;;;;;;;;;;;;;;;GAqBG;AACH,wBAAgB,kBAAkB,CAChC,SAAS,EAAE,mBAAmB,EAAE,GAAG,IAAI,GAAG,SAAS,GAClD,KAAK,CAAC;IAAE,KAAK,EAAE,MAAM,CAAC;IAAC,KAAK,EAAE,MAAM,CAAA;CAAE,CAAC,CAUzC;AAED;;;;;;;;;;;;;;GAcG;AACH,wBAAgB,sBAAsB,CACpC,SAAS,EAAE,mBAAmB,EAAE,GAAG,IAAI,GAAG,SAAS,GAClD,OAAO,CAKT;AAED;;;;;;;;;;;;;;;;;;GAkBG;AACH,wBAAgB,iBAAiB,CAC/B,OAAO,EAAE;IAAE,IAAI,CAAC,EAAE,OAAO,CAAC;IAAC,SAAS,CAAC,EAAE,OAAO,CAAA;CAAE,GAAG,IAAI,GAAG,SAAS,EACnE,QAAQ,CAAC,EAAE;IAAE,QAAQ,CAAC,EAAE,OAAO,CAAA;CAAE,GAAG,IAAI,GACvC,OAAO,CAMT;AAED;;;;;;;;;;;;;;;;;;;;;GAqBG;AACH,wBAAgB,aAAa,CAC3B,OAAO,EAAE;IAAE,IAAI,CAAC,EAAE,OAAO,CAAC;IAAC,WAAW,CAAC,EAAE,OAAO,CAAA;CAAE,GAAG,IAAI,GAAG,SAAS,EACrE,QAAQ,CAAC,EAAE;IAAE,QAAQ,CAAC,EAAE,OAAO,CAAA;CAAE,GAAG,IAAI,GACvC,MAAM,CAUR;AAED;;;;;;;;;;;;;;GAcG;AACH,wBAAgB,iBAAiB,CAC/B,MAAM,EAAE;IAAE,OAAO,CAAC,EAAE,OAAO,CAAA;CAAE,GAAG,IAAI,GAAG,SAAS,EAChD,OAAO,CAAC,EAAE;IAAE,YAAY,CAAC,EAAE,OAAO,CAAA;CAAE,GAAG,IAAI,EAC3C,GAAG,CAAC,EAAE,MAAM,GACX;IAAE,EAAE,EAAE,MAAM,CAAC;IAAC,IAAI,EAAE,MAAM,CAAA;CAAE,GAAG,IAAI,CASrC;AAED,yFAAyF;AACzF,wBAAgB,eAAe,CAAC,EAAE,EAAE,MAAM,GAAG,MAAM,CAUlD;AAcD,MAAM,MAAM,WAAW,GACnB,QAAQ,GACR,UAAU,GACV,SAAS,GACT,QAAQ,GACR,SAAS,GACT,MAAM,CAAC;AAEX,MAAM,WAAW,YAAY;IAC3B,eAAe,CAAC,EAAE,MAAM,GAAG,IAAI,CAAC;IAChC,0EAA0E;IAC1E,MAAM,CAAC,EAAE,MAAM,GAAG,IAAI,CAAC;IACvB,yEAAyE;IACzE,WAAW,CAAC,EAAE,OAAO,CAAC;IACtB,MAAM,CAAC,EAAE;QAAE,IAAI,CAAC,EAAE,OAAO,CAAC;QAAC,KAAK,CAAC,EAAE,OAAO,CAAC;QAAC,UAAU,CAAC,EAAE,OAAO,CAAA;KAAE,GAAG,IAAI,CAAC;IAC1E,UAAU,CAAC,EAAE;QAAE,cAAc,CAAC,EAAE,OAAO,CAAC;QAAC,SAAS,CAAC,EAAE,OAAO,CAAC;QAAC,cAAc,CAAC,EAAE,OAAO,CAAA;KAAE,GAAG,IAAI,CAAC;CACjG;AAED;;;;;;;;;GASG;AACH,wBAAgB,UAAU,CAAC,KAAK,EAAE,YAAY,GAAG,WAAW,CAuB3D;AAED;;;;;;;;;;;GAWG;AACH,wBAAgB,WAAW,CAAC,SAAS,EAAE,mBAAmB,EAAE,GAAG,IAAI,GAAG,SAAS,GAAG,OAAO,CAQxF;AAED,8EAA8E;AAC9E,wBAAgB,YAAY,CAC1B,MAAM,EAAE;IAAE,MAAM,CAAC,EAAE;QAAE,IAAI,CAAC,EAAE,OAAO,CAAC;QAAC,KAAK,CAAC,EAAE,OAAO,CAAC;QAAC,UAAU,CAAC,EAAE,OAAO,CAAA;KAAE,GAAG,IAAI,CAAC;IAAC,OAAO,CAAC,EAAE,OAAO,CAAA;CAAE,GAAG,IAAI,GAAG,SAAS,GAC1H;IAAE,IAAI,EAAE,MAAM,CAAC;IAAC,KAAK,EAAE,MAAM,CAAC;IAAC,UAAU,EAAE,MAAM,CAAC;IAAC,SAAS,EAAE,MAAM,GAAG,IAAI,CAAA;CAAE,GAAG,IAAI,CAiBtF;AAED;;;;;;;;;;;;GAYG;AACH,wBAAgB,eAAe,CAC7B,OAAO,EAAE;IAAE,aAAa,CAAC,EAAE,OAAO,CAAC;IAAC,QAAQ,CAAC,EAAE,OAAO,CAAA;CAAE,GAAG,IAAI,GAAG,SAAS,EAC3E,OAAO,EAAE,KAAK,CAAC;IAAE,IAAI,CAAC,EAAE,MAAM,CAAA;CAAE,CAAC,GAAG,IAAI,GAAG,SAAS,GACnD,MAAM,GAAG,IAAI,CASf;AAED,kEAAkE;AAClE,wBAAgB,eAAe,CAC7B,OAAO,EAAE;IAAE,WAAW,CAAC,EAAE,OAAO,CAAA;CAAE,GAAG,IAAI,GAAG,SAAS,GACpD,MAAM,GAAG,MAAM,GAAG,MAAM,GAAG,MAAM,CAGnC;AAeD,MAAM,MAAM,UAAU,GAAG,KAAK,GAAG,OAAO,GAAG,SAAS,CAAC;AAErD,MAAM,WAAW,SAAS;IACxB,IAAI,CAAC,EAAE,OAAO,CAAC;IACf,KAAK,CAAC,EAAE,OAAO,CAAC;IAChB,8DAA8D;IAC9D,SAAS,CAAC,EAAE,OAAO,CAAC;IACpB,qEAAqE;IACrE,OAAO,CAAC,EAAE,OAAO,CAAC;CACnB;AAED,MAAM,WAAW,cAAc;IAC7B,IAAI,EAAE,UAAU,CAAC;IACjB,8EAA8E;IAC9E,IAAI,EAAE,MAAM,GAAG,IAAI,CAAC;IACpB,SAAS,EAAE,MAAM,GAAG,IAAI,CAAC;IACzB,oDAAoD;IACpD,OAAO,EAAE,MAAM,CAAC,MAAM,EAAE,MAAM,CAAC,CAAC;CACjC;AAED;;;;;;;;;;;;GAYG;AACH,wBAAgB,aAAa,CAC3B,MAAM,EAAE,SAAS,GAAG,IAAI,GAAG,SAAS,EACpC,WAAW,GAAE,CAAC,CAAC,EAAE,MAAM,KAAK,MAAiB,GAC5C,cAAc,GAAG,IAAI,CAqCvB"}
|